Some Programming Challenges

[airship]

I tend to think of myself as a bit of a hacker in that I can play with BASIC, and PEEKs and POKEs, and I can ferret out information from a manual to get a CBM machine to do some fun stuff. I even dabble a bit in assembler. But I'm just not good enough to implement the crazy things I THINK about. That being said, here are some of my crazier ideas for you REAL programmers to chew on. Hopefully you can come up with some programs that actually DO these things!

(1) A serial network for C64s and C128s. In Twin Cities 128 (I think #31 or so) there was an article about setting up two serial devices to talk to one another without the computer's intervention. In a nutshell, it told one to TALK and one to LISTEN and then let them go at it. This could be used for copying files from one drive to another, or for spooling a file from a drive to a serial printer. (He had a short BASIC program listing that would actually spool from drive to printer.) Very cool stuff, and I don't think I've EVER seen this used in a real-world program. (Why not?) Anyway, it got me thinking: would it be possible for two (or more) CBM computers to network in this way? It seems to me that you'd have to set them up to believe they were numbered devices on the IEC bus, then get them to TALK and LISTEN just like a serial peripheral. How tough would this be? And could you get multiple computers and peripherals to behave so you could have them all communicating nicely with each other? Then you could share a printer or a 64HDD hard drive.

(2) Could you set up a 1571 to think it's a dual drive? You can put it into single-sided mode with "U0>M0", then tell it to use the bottom side of a disk with "U0>H1" and the top side with "U0>H0". (I think that's right, though it may be reversed...) In this mode, each side acts like a separate disk. Is there some SIMPLE program (simple, as in it will fit in drive RAM and still leave enough room for normal operations) that would reprogram the 1571 to think it's a dual drive, like the 8250? That is, so it would respond to commands sent to 0: as the normal bottom side, but 1: to the top? I don't really see how this would be very useful, but I think it would be an interesting programming project. The real test would be if it would work with the COPY command.

(3) Task switching. I've seen little demos and attempts at great-big operating systems that try to do some task switching on the C128, but I don't think I've ever seen a serious attempt to actually implement it. I would LOVE to be able to work on two BASIC programs at once, or keep a memory-resident notepad, calculator, etc., around to bring up at a keystroke. But though I've seen a few individual resident utilities that do this, I haven't really seen anything that lets you just switch between any two (or four, or whatever) real programs. Have I missed something? Is there something out there that does this, or do you guys want to take on this challenge yourselves? Why do I care? Well, there's that article in TC128 issues #30-31 about increasing your C128 to 512K using 4 RAM banks...

(4) PIP (Picture in Picture). Give me a utility that would pop up a window on the C128's 80-column screen that accurately shows the 40-column screen. I'd settle for text and character graphics to start with, but if you can show me changing bitmaps and split-screens in real time, that would be WAY cool! Oh, and I want to  be able to flip it to any of the 4 screen quadrants. And to show up to 4 different screens from memory, whether they're displayed or not. Use FAST mode since I don't need to look a the actual 40-column screen any more. Let me edit it interactively, too. Now, how hard could that be?

I've got a long list of ideas like this, but I'll give you a break for now so you can run off and work on getting these implemented. I'll be back later to check on your progress.

[hydrophilic]

My thoughts on these ideas.

1.  This is doable but would need extra code because the KERNAL ignores the ATN line which is how commands are sent to devices.  An important consideration is the ATN input is not in the same register as the the other serial lines (CLK/DATA in/out); if I remember correctly (a big if) the ATN input goes to CIA#2.  Since a device needs to respond to ATN in 1ms, an interrupt would be needed.  I don't know if this line can generate an interrupt and even if it can, it would be NMI which is more troublesome than a normal IRQ

2. With only about 1K to work with, it would be really cool hack to pull this off.  The biggest problem is the CBM drives don't have a lot of vectors like BASIC and the KERNAL.  So it seems a great deal of the ROM would have to be duplicated...

3. This is very doable except for BASIC strings.  Since other variable types and BASIC programs grow from the bottom of memory up, it should be easy to swap pointers to have multiple programs.  But with strings built from the top down, you'd have to reset the upper memory limit on program swap (assuming variables are not shared).  Changing the upper limit is not hard, but you would need to plan ahead.  You could divide bank 1 in half an then have 2 programs but not 3 or 4.  Or you could divide bank 1 into fourths and have up 4 programs, but the variable size would be quite limited...

I guess it would need to be a dynamic program that reallocates memory as you add new programs.  Sounds like a lot of work for a variable number of programs.  I might try to get 2 or 3 working using a fixed memory allocation for fun, but don't hold your breath!

4.  There are two problems with using a quadrant of the VDC screen for a VIC image.  First, the vertical resolution is the same on both chips so for a quadrant sized VIC image you would need to turn on VDC interlace (which some people would object to) or you could compress the VIC image vertically.  Not only would compression result in a distored image (which may be acceptable) but then 8x8 blocks become 8x4 so that 2 chars are in the same color cell.  The color distortion would probably be more anoying than the vertical compression.  Of course the VDC color cells could be made 8x4 in size but then the whole memory arrangement would change so that new 80-column KERNAL routines would be needed.  Any app that by-passed the KERNAL would fail miserably.

The second problem is there is no way (to my knowledge) to emulate multi-color VIC images on the VDC.  A related problem is extended background color graphics.  Not widely used but if necessary could be emulated with a bitmap.  To have a color bitmap on the VDC would require a 64K RAM version.  More importantly, it seems the entire screen would need to be bit-mapped in this case which means very slow text editing.

The closest I have come to that idea is not really close, I just used the whole screen and turned on 'pixel double-width' mode of the VDC.  It looks very very much like a VIC display but only for non-multicolor.  Plus it uses the whole display not a quadrant.

-------------
OK those are some good challenges.  Some pretty tough which is probably why they haven't happened.  I'll play around with #3 (multiple programs) and see if anything springs up.

[airship]

My thoughts right back atcha:

1. Here's what the C128 Service Manual says about IEC serial communication:

Bus Operations
There are three basic bus operations that take place on the serial bus, in both fast and slow modes. The first of these is called Control. The C128 is the controller in most circumstances. The controller of the bus is always the device that initiates protocol on the bus, requesting peripheral devices to do one of the two other serial operations, either Talk or Listen.
All serial bus devices can listen. A Listener is a device that has been ordered by the Controller to receive data. Some devices, such as disk drives, can talk. A Talker can send data to the Controller. Both hardware and software drive this bus protocol.
The Standard (Slow) Serial Bus
The slow serial bus uses the port lines of the 6526 at U4, C1A 2, to drive ATN, ClK and DATA. The operation is the same as that of the C64 and when in C64 mode, slow to fast interference is automatically removed.
The Fast Serial Bus
In order to talk as a fast talker, the Controller must be addressing a fast device. When addressing any device, the C128 sends a fast byte, toggling the SRO line eight times, with the ATN line low. If the device is a fast device, it will record the fact that a fast Controller accessed it and respond with a fast acknowledge. If the device is a slow device, no response is delivered and the C128 then assumes it is talking with a slow device. The status of the fast or slow is retained until the device is requested to untalk, unlisten, or if an error or system reset occurs.
The fast serial bus, in order to achieve its speed increase, uses different hardware than that of the slow serial bus. The fast serial method is to use the serial port lines of the 6526 U1, CIA 1, pin 39, to actually transfer the serial data. This increases the transfer rate dramatically.
The FSDIR bidirectional control line signals the MMU at U7, pin 44, that a fast device is present. The MMU then outputs control signals to the data direction buffer hardware for fast serial operation.

So all of the lines (including ATN) are connected to a single 6526 for SLOW serial communication, though FAST communication uses a port on the 2nd 6526 and gets the MMU involved, as well. Sounds like slow would be much easier to implement than fast.
I like what it says in the first paragraph. This description seems to imply that two or more computers could easily pass the role of 'controller' back and forth under some kind of protocol, and be assigned a device number under which they just TALK or LISTEN unless they are the designated controller. Cool.
With slow serial networking, you could set up a bunch of C64s or C128s as a Beowulf cluster. (Yes, I know they're doing something like this at an upcoming vintage computer conference to create a multi-SID orchestra, maybe even using a method similar to this one??)

2. You still have entry points for ROM subroutines, you just don't have vectors. So you'd have to query the ROM in the 1571 for its version number, and look up the proper subroutine entry points in a table in the C128 program. Then you could upload customized code to the 1571 with these entry points inserted into your routine. Fun, huh?

3. Like you say, you can change the pointers to the various starts and ends of memory for both program space and variables. Use a small block in page 1 to keep track, right? I'd be happy if it was just BASIC 7 workspaces for small to intermediate size programs. That's all I need.

4. Duh. I forgot about the vertical resolution thing. OK, so we start with an 80x50 interlaced text screen on the VDC, and just worry about a single mirror of the current VIC text screen to start with. How about that?

[nikoniko]

4. Is PIP important? Instead you could do full screen and have an assigned key cycle through each screen, thus avoiding interlace. Or, briefly switch to interlaced mode and display 4 40-column screens, and then you select one to work on and it becomes full screen. Could be nice combined with your multitasker.

[airship]

I like the idea of switching to interlace simply to preview 4 screens. You could cycle through more screens with page or cursor keys, then pick one to view with a number or function key. But I don't see the utility of translating a 40-column screen to the 80-column screen in the final display mode, since you could just flip to the 40-column screen itself. Unless you're just looking for a programming challenge, of course.

[nikoniko]

But I don't see the utility of translating a 40-column screen to the 80-column screen in the final display mode

Fingers don't need to leave the keyboard to hit the video switch.

[hydrophilic]

You have to be very carefully when trying to interpret Commodore's literature...

...1. Here's what the C128 Service Manual says...

...The slow serial bus uses the port lines of the 6526 at U4, CIA 2, to drive ATN, ClK and DATA...

The problem is READING the ATN line.  I was wrong on my previous assumption.  The ATN input does not go to the other CIA.  It goes NO WHERE!!  Well, it actually goes to a pin on the user port (but not to any chip).

So to have a network using standard CBM protocol (slow or fast mode) would AT LEAST require:
a) A jumper wire from the user port pin 9 to something that could trigger an interrupt (such as pin B on the user port that connects to CIA 2 /FLAG).
b) A revised KERNAL to actual monitor and respond to serial bus commands.

I would be interested to see how the multi-SID orchestra is networked.  I bet its a custom protocol incompatile with CBM serial devices.

2. I still don't think its possible but I'd love to see the code if anybody does it.

3. I've made a beta-version of this.  Uploading soon to a server near you. Edit: Download the ZIP with binary files, a text discription (ReadMe), and a compiled D64 image.  An HTML discription is also available here.  Can we cross this off the list now?

4. If interlace is OK then a VIC quadrant on VDC is very do-able.  It would be a tight fit with only 16K RAM however.

[airship]

3. KEWL!!! It's Saturday, so I've got to go run errands, but I'm REALLY looking forward to trying this out when I get back!

2. As mentioned my post above, in a weird bit of synchronicity, just as I was starting to think about this idea, I started scanning in the 'Expanding C128 RAM to 256K' two-part article in a couple of Twin Cities 128s that I had just bought on eBay. In the second magazine, there are TWO articles on this subject: 'Driving the Serial Bus' and 'Spooling with Commodore Drives'. The second is a BASIC program that lets you copy directly from one drive to another, or spool a file directly from a drive to a printer. I'm planning on scanning those once I'm done with the RAM article, and when I get them uploaded I'll post a link here.

Of course, you're right about the ATN line being send-only, so that's a deal-breaker without a hardware mod. And you'd have to wire it so that the computer didn't respond to its OWN outgoing ATN signal as an incoming interrupt!

Unless the computers on the network just listen to every byte sent on the serial bus, and recognize their commands programatically. Seems like that would take a lot of processing time. OR you could have a designated 'master control' computer handling communications. It would sit on the bus and monitor traffic. If any computer on the network wanted control, it would have to listen, then during a quiet spot ask for permission to talk. It would then have to listen for permission, which the master controller wouldn't give until it knew that any current communication processes were over. A little more complex, but you can buy a working C64 for $10, and one with a dead SID chip for $5.

[airship]

Hydrophilic, I have now had a chance to try out your solution to challenge #3, and I've got to say I'm pretty impressed that you did this all in one night, wow!

It worked very well for most 'normal' stuff. I was able to keep a copy of the ZED text editor in one area while loading and running programs in the other. This alone addresses one of my major complaints with the C128 - no resident 'more' command.

Anyway, it should be great for working on two BASIC programs at once, or keeping ZED resident so I can actually read documentation without having to wipe out the program I'm working on.

As you say, it's for BASIC work only. I was able to run a few small applications, but I couldn't do things like run a self-extracting archive. HOWEVER, when I did a soft-reset to break out of the lock, imagine my surprise when I was still able to swap back to the other area and find my program there intact!  That alone is worth, as they say, the price of admission!

I was also surprised that my the KEYS definitions were the same, along with defined windows, etc. Nice.

All in all, a very, very good 'quickie' that addresses the need at hand extremely well. As I said, I'm impressed. If I was still writing reviews for INFO, this one would have gotten four stars for sure!  '****' -MRB  

Now, a question about #2 (glory is so fleeting!), if ATN isn't hooked up on the C128, and the schematics certainly say not, then why does my C128 hang up until my 64HDD server comes online? Is it just because the 128 boot sequence (which is run by the Z80) is looking for drive 8 and can't get an answer back? I assume this is it, because it works just fine to shut down the 64HDD server after the 128 boots.

[Blacklord]

Could this be used as the bones for a multitasking OS ?

[airship]

Hey, as far as I'm concerned, it IS a multitasking OS!

It just depends on your definition. This is strictly task-SWITCHING, and it's a little touchy if you try to get fancy. But most BASIC stuff runs fine, and I've even run some simple utilities from one while keeping the other pristine.

I can run a utility in one area while I program in another, or I can write two BASIC programs at once. They share the same screen, so to copy lines from one to another, all I have to do is list those lines, switch, and hit RETURN on each line I want to copy.

While it pukes if you try to switch under program control, I have already run two short programs that switch by using the old 'print RUN then poke the keyboard buffer with a chr$(13) trick. Pretty slick.

Maybe we should call it HydrOS.

[Guest]

I'd be very, very careful about using ZED with this technique and ZED doesn't know about the "other program" and will like clobber it if you load a file that's too big.

This is the challenge of creating a multi-tasking system, you have to provide memory protection and allocation for individual programs in the OS, which 99.999% of Commodore programs assum they have complete control over.

[hydrophilic]

Four stars! :cool: Thanks for mentioning the reset 'feature' -- that's sure to come in handy.

I don't know what the boot-up problem is... I can only gues that DATA is being grounded (the Commie thinks somebody is listening in that case and waits for it to go +5V before sending command).  

BTW, let me take the opportunity to dispel the myth about the Z80 checking the disk (I've seen this mentioned numerous times). The Z80 only checks for a cartridge or Commodore key and will GO64 if so; otherwise it hands control to the 8502 (in 128 mode of course).  The 8502 does the disk check.

Could this be used as the bones for a multitasking OS ?

More like an experimental starting point.  It's mainly like an automated STASH/FETCH without an REU!  However co-operative multi-tasking is possible (but unreliable); i.e. program 0 can activate program 1 which can later re-activate program 0, etc.  I did some tests and with this and sometimes it will crash.  I'm not sure why, but probably has to do with the CPU stack.

A LOT more work would be needed for even a simple but reliable multi-tasking system.  Not only would this entail more code (i.e., more memory) but the amount of data saved for each task would need to increase quite a bit (yet more memory).

Also a multi-tasking version should, I think, dynamicaly allocate the memory needed.  Right now the memory assignment is fixed.  It shouldn't be a lot of trouble to change but I've been wrong before...

[nikoniko]

It's mainly like an automated STASH/FETCH without an REU!

Hmm... REU would be a great way to accomplish much the same that you have while making the full memory space available to each program. Load something, stash RAM 0 and RAM 1 in REU, load up something else, stash that or swap it with the previous store, etc. The number of states you could save would only be limited by the amount of RAM in the REU.

[hydrophilic]

Nikoniko scares me.  Always reading my mind!  There are a lot of things you could do with this idea.  I just kept simple as a proof of concept.

If you use the Reset 'feature' be sure to do nothing in program space 0, because BASIC will have reclaimed all of memory (in particular any strings created here will destroy strings in your highest memory space).  It's best to save program 1 (and 2 if available) as neccessary then SYS the install routine again.

[airship]

I saved both of my little demo programs, then rebooted, set up the memory partitions, then loaded them into their separate workspaces and ran them. They worked great! Now my mind is working, too...

Oh, and BTW, I've got a 1764 REU, so I'm interested. I know that the DMA from the REU can actually swap memory in and back faster than the C128 can swap it internally. So that's intriguing. Mine is 256K, which is 4x a single bank, so hummm...

Combine that with Hydrophilic's workspace swapping and what have you got? A dozen or so potential workspaces? All of them able to transfer control to one another ? This is sounding like FUN!

BTW, I've got three little demos sharing the same screen very happily right now. It is so fun to watch! :förvånad:

[hydrophilic]

Co-operative multi-tasking on a C128 It is a rather strange programming method!

The one thing you should know about an REU method is it would not be as fast.  This N-Progs mostly swaps pointers (program and variable memory is NOT moved).  The only memory it moves (besides the pointers, less than 64 bytes) is the BASIC stack which is only 512 bytes (half a VIC screen w/o color).

Now the REU is fast, but swapping an entire program and all variables would take a noticeable amount of time.  That is, it wouldn't seem to be 'instantly' like the current version.  (unless your program is really small w/few variables).  So co-operative multi-tasking wouldn't be nearly as fun / practical.

On the other hand, it would very compatible with other apps since they would get (almost) all the memory normally available and all the pointers (except 1: top of BASIC text) would be the same as normal.  So you would be traiding increased memory and compatibility for decreased speed.

Blah, design decisions!

Right now though, I was thinking about a practical method for the VIC screen on the VDC.  (Challenge #4).  Bitmap mode could be used only if you have 64K RAM (16K is not enough for interlaced bitmap) and more importantly, text would have to be actually drawn on the screen which, besides needing a patch to the KERNAL, would severly slow down text-based programs.

You do want some type of text display/editing while the VIC screen is displayed right?

If instead you used VDC text mode, that would mean 4K for 80x50 text screen and another 4K for 80x50 attributes, plus 4K for one font (the main text).  I was thinking we would just use the alternate font to construct the VIC image, so another 4K.  This adds up to 16K.

But this seems like it would only work if VIC was producing a text display.  For a VIC bitmap (8K) a single font wouldn't work.  I was thinking the dreaded 'virtual raster IRQ' technique to change fonts half-way through the VIC image.

If this could be done with two font sets, we would need another 4K for the second set so it seems we would go over the 16K limit.  But then I thought about nikoniko's post about interleaved screen memory.  Well the VDC font has an 8-byte gap between every character in its font definition, so maybe the same idea could be used with fonts!

That is, squeeze two font sets into the 4K normally used by one set.  Since there are two font sets to begin with, we could actually have 4 font sets plus text and attributes all in 16K.  1 font for the normal text of VDC, and 3 fonts to construct the VIC image.

Unfortunately we would need 4 fonts to construct the VIC bitmap image unless we used some sophisticated mapping system to reduce redunancy.  Couple that with the virtual VDC IRQ and you've got one tough order to fill...

Anybody have some thoughts on this issue?

[bacon]

Now the REU is fast, but swapping an entire program and all variables would take a noticeable amount of time.  That is, it wouldn't seem to be 'instantly' like the current version.  (unless your program is really small w/few variables).  So co-operative multi-tasking wouldn't be nearly as fun / practical.

I'm not so sure about that. I did a little REU programming a few years back and from what I remember you set up a few registers to tell the REC chip in the REU which area of internal memory should be swapped (bank 0 or 1 + memory range), and which REU bank should be used, and then tell it to start. The REC chip then takes over and does the swap using DMA. No ML loops to go through one page at a time or anything; it swaps a whole RAM bank in one fell swoop if need be. With a throughput of 1MB/s even swapping both internal RAM banks at once seems instantaneous.

I made a utility that I use with Buddy 128 which does just that and there's no discernible delay.

You can see this for yourself with any of the C64 Turbo Assembler versions hacked for REU use.

[nikoniko]

If this could be done with two font sets, we would need another 4K for the second set so it seems we would go over the 16K limit.  But then I thought about nikoniko's post about interleaved screen memory.  Well the VDC font has an 8-byte gap between every character in its font definition, so maybe the same idea could be used with fonts!

I had wanted to do that for something I was playing around with, but unfortunately the character set start address isn't very flexible. Three bits in register 28 define the most significant bits of a 16-bit address, and the rest of the address is all zeroes. You don't get the nice total control that you do with the screen and attributes.

[airship]

3. Even if REUs wouldn't be as fast, I was thinking about having 2-3 programs in RAM, and swapping into the idle areas, not the active one. DMA is pretty much invisible to a running program, isn't it?

4. Heck, I would have been happy with just displaying a VIC text screen in 1/4 of an 80x50 interlaced VDC screen.  But I LOVE all this talk about character sets and interleaved screen memory! If it can't be used for this, what CAN it be used for? Any programming examples yet?

2. Not much talk on this one yet. A wedge in drive RAM could interrupt requests to drive 1: and change them to drive 0:, but would do the switch to the bottom side of the disk first, and vice-versa. It would treat commands with no drive number as meaning drive 0:, just as CBM DOS normally does. Of course, first it would have to lock the 1571 into 1541 mode when it started up. It would have to correctly implement the COPY files and DUPLICATE commands, of course. If it won't fit in standard RAM, how about with a 1571 RAMBoard? Better yet, how about burning a new 1571 ROM?

1. Scanning in those TC128 articles is still next on my to-do list.

[hydrophilic]

Bacon, I agree the REU is very fast.  At 1M/s, it would take about 1/9 second to transfer 128K.  This would seem 'instant' executed in immediate mode, but would be evident (not so instant) when programs are multi-tasking...

Blah!  I guess it would be really dependant on the programs (how often they switched).  I guess one would need to try it (REU multi-tasking) and find out.
  Of course if your goal was simple task-switching (not multi-tasking) the REU is excellent.

Or you could go with airship's idea and do both!

Three bits in register 28 define the most significant bits of a 16-bit address, and the rest of the address is all zeroes. You don't get the nice total control that you do with the screen and attributes.

AHHHHHHHH. I was afraid of that.  So it would have to be a VIC text screen or else you'd have to bitmap the VDC w/64K required... unless somebody has a better idea?

2. Burning a new ROM would be the easiest (for those with EPROM burners).  Otherwise, the only RAM vector I know of is the IRQ.  This could be used to intercept commands, and you'd have to parse them.  Not just the channel 15 commands, but the low-level TALK/LISTEN/etc, plus the channel (not 15) read/writes.  That's a lot of stuff to fit in RAM.  True, there is a jump table, but this is mostly for low-level (controller) stuff and we need hi-level (file/command) level routines.  So more RAM would make this idea more feasable.  Heck, I won't even say it's not possible with standard RAM, but it would be one great hack if possible.

BTW, you do know that writting to the flip-side with the U0>H1 command produces incompatible disks?  (the data is written backwards).

[airship]

I'd settle for a new ROM. I'm going to be getting a burner as soon as I can afford it. What's in there now that can be safely gotten rid of? I don't suppose it has the address lines for a bigger ROM? (Too lazy to look right now.)

I've always loved the fact that the backside of a 1571 in single-sided mode can only be read on a 1571. When I did the original review of the 1571 drive for INFO, Benn's reaction was, "You're kidding me," because it didn't say that in the manual. I patiently explained about how the water in a bathtub drains opposite ways north and south of the equator...

Anyway, re: #1, here's the first short program listing for serial spooling from drive to printer. Note that whereas this example has everything hard-coded, the example to come is user-selectable.

Code Select Expand

5 rem c128 spool drive-to-printer
10 a=11         :rem device no. source drive
15 b=4          :rem device no. printer
20 sa=0         :rem secondary address
25 open 1,a,15  :rem open command channel on source
30 open 2,a,sa,"0:readme.1tr,s,r" :rem open source file for reading
35 open 3,b,sa  :rem open printer
40 tk=2*16 or b :rem listen address of destination
45 print#1,"m-w"chr$(120)chr$(0)chr$(1)chr$(tk) :rem change address
50 s=6*16 or sa :rem secondary address command byte
55 sys 58174,b  :rem send listen
60 sys 58578,s  :rem send secondary address command byte
65 sys 58687    :rem release bus (data & clock lines high)
70 input "press when done printing";a$
75 sys 58662    :rem send unlisten
80 sys 58645    :rem send untalk
85 tk=4*16 or a :rem original talk address of source
90 print#l,"m-w"chr$(l20)chr$(0)chr$(1)chr$(tk) :rem restore address
95 close 2: close 3: close l: rem close channels

[nikoniko]

Isn't 1Mb/s the rate for fetch or store? So wouldn't swap be half that since it has to do both? That would bring us closer to the 1/4 second range, which still wouldn't be bad as long as tasks don't switch too often. Anyway, I had really imagined the REU swapping idea to be less for multitasking than for having easy access to several programs, and it sounds like it would work very well for that.

[hydrophilic]

Nice code airship.  I forgot about reprograming the drive's talk address.  It's also interesting you never send the drive a TALK command.  I guess it does that 'naturally' when a file is opened and somebody is LISTENing?

I was thinking if we could detect ATN w/o a hardware mod in a sneaky way.  When the C128 brings ATN low, devices should release CLK (go high) and bring DATA low (indicating a listener).  Just after bringing ATN low, the C128 should also bring CLK low (indicating a talker).  But we could reprogram the KERNAL to not bring CLK low.  We could keep the bus in this 'bad state' (CLK hi, ATN low) for 2 IRQ cycles.  Thus another computer on the bus could check in its IRQ if an ATN was starting by looking for the state CLK hi, DATA low.  If it found this state, it would just a loop a few microseconds to see if its 'constant' because it could also happen for a moment when sending a byte.

I'm not sure how useful that would be.  Some devices might not like it.

Also, when no device is active (no talker or listeners), both CLK and DATA should be high.  If a computer wants to use the bus, it should look for this and if it finds it, just do a loop to be sure it is 'constant' because, again, this could happen momentarily during a byte transfer.  The only problem is if a C64 is connected.  A bug in the ROM sets the CLK low on power up (this is rectified after doing any serial I/O).

Good call nikoniko.  I was only thinking one way.  1/4 second, ouch!  On the plus side, you wouldn't normally transfer all 128K.

[bacon]

Bacon, I agree the REU is very fast.  At 1M/s, it would take about 1/9 second to transfer 128K.  This would seem 'instant' executed in immediate mode, but would be evident (not so instant) when programs are multi-tasking...

Yeah, I was stuck thinking along the lines of task switching.