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. :D
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.
My thoughts right back atcha:
1. Here's what the C128 Service Manual says about IEC serial communication:
QuoteBus 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?
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.
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. :)
Quote from: airshipBut 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. ;)
You have to be very carefully when trying to interpret Commodore's literature...
Quote from: airship...1. Here's what the C128 Service Manual says...
Quote...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 (http://sites.google.com/site/h2obsession/CBM/C128/images/N-PROGS.ZIP) the ZIP with binary files, a text discription (ReadMe), and a compiled D64 image. An HTML discription is also available here (http://sites.google.com/site/h2obsession/CBM/C128/n-progs). Can we cross this off the list now? :P
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.
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. :)
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.
Could this be used as the bones for a multitasking OS ?
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. :)
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.
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.
Quote from: adminCould 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...
Quote from: hydrophilicIt'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.
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.
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:
Co-operative multi-tasking on a C128 :P 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?
Quote from: hydrophilicNow 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 (http://turbo.style64.org/) versions hacked for REU use.
Quote from: hydrophilicIf 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.
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. :)
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!
Quote from: nikonikoThree 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).
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... :D
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.
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
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.
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.
Quote from: hydrophilicBacon, 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.
re: #1 - I've uploaded a ZIP file that contains the following files:
The two Twin Cities 128 articles on serial spooling
Two txt files of the program listings
Two C128 program files derived from the listings
http://home.mchsi.com/~airship1/serial.zip
I think you'll find them very interesting. I did.
DISCLAIMER: The PDF is from page scans that I spent a LOT of time cleaning up, so it should read pretty accurately. The program listings were OCRed from the PDF. Though I've been through them several times, they may still contain errors. The program files were automagically generated by Tok64, then loaded to see if they looked ok in VICE. They should be fine, but I had to OCR them here at work and I haven't been home to actually run them yet. Though I DO have VICE up and running here, I really don't trust it to do much of a job on programs that use m-r and m-w commands. :)
Hello guys, I'm new here. Nice forum!
Quote from: hydrophilicBacon, 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...
I don't think you can implement multitasking on top of the existing DOS and using the existing set of applications.
With the C128's standard Kernel, there's no way of running an application "in the background" - if it runs, it grabs/requires all the ressources available. Imagine you're editing a text with ZED in 'task' 1, while task 2 (running in the background) would be a game of Reversi.
As soon as the Reversi game would have finished calculating the computer's move, it would listen to keyboard input again. The next time the task switcher activates Reversi's task, it would empty the keyboard buffer - i.e. eat up key strokes that were actually intended for the other task. Another problem would be that both tasks require access to the video RAM, so you'd have to switch displays aswell as tasks. Multitasking can't be that much fun if your display is switching from ZED to Reversi two or three times per second.
If you really want to have real multitasking, you'd better use a dedicated OS, like the C128 port of Lunix.
But the idea of using a REU for task switching sounds very nice, especially as C128 software should be pretty compatible with that kind of approach (no fancy raster interrupts or stuff like that).
Hydrophilic, I did not understand a word you said. Cool. You've given me a lot to research.
I just made a bid on SIX 1541s. I'm thinking of using one with its drive intact as a master, stripping out all the other drives, and stacking the boards to make a parallel machine: one master, six slaves, and a C64 on the bus for setup, input, and display. Of course, it would use the serial bus to communicate, just as we're discussing here.
I believe that the parallel stack controller would have the opposite problem of the computer: whereas the computer has no easy way to listen for ATN, the master 1541 would have no easy way to generate ATN. Right?
I've already thought that it might be cool to implement a cryptography program. Each program would get a block of 256 characters to encrypt at a time. They'd be encrypted, then sent back to the master for storage on the disk. One thought I had was to implement the ROM routine for GCR encoding as part of the encryption scheme. :)
You could also calculate digits of PI in parallel and store 170k digits on each floppy.
Quote from: airship...whereas the computer has no easy way to listen for ATN, the master 1541 would have no easy way to generate ATN. Right?
Right the Commodore disk drives can't output ATN. But it would be an easy hack to allow this. The 1541,71,81 all have unused output lines on their I/O chips (this is also how the parallel I/O hacks work). Of course you would a need a little more power to drive the line. I think the '41 has an unused gate that could work, but you'd probably need to add a small chip ($0.25) for the '71,81.
Quote from: airshipYou could also calculate digits of PI in parallel and store 170k digits on each floppy.
:D :D :D
If you used that for encryption, that'd be 170*1024*8 = 1,392,640-bit encryption. Better not publish such a program or you'd be in violation of cryptography export laws! With such an insane bit length, even the NSA/CIA/FBI/KGB/FSB (all working together) couldn't crack your message... except the digits of PI are well known. (but do they know the GCR coding of PI ?)
Quote from: KorodnyI don't think you can implement multitasking on top of the existing DOS and using the existing set of applications.
N-Progrs does implement a very primitive co-operative multi-tasking with existing BASIC apps that don't use DOS commands. In this limited case, programs are aware of each other so shouldn't have problems you mentioned.
However, you made very valid points to be considered for pre-emptive multi-tasking. Such a system (unlike N-Progs) would need to:
1) manage files seperately for each task
2) maintain seperate keyboard/input buffers
3) maintain seperate screen/output displays
Obviously #1 would be the biggest challange. #2 is trivial since the keyboard buffer is only 10 bytes. #3 could be done in two ways: if the app uses standard KERNAL I/O for screen, you could just use seperate memory for screens (this would be fast); otherwise you'd have to copy memory to the 'standard' location on task switch (slow but more compatible).
I also agree if you want true, reliable multi-tasking it is best to go with an OS desgined for it. But this has the severe disadvantage that you have to throw away all your existing apps.
EditQuote from: airshipI've uploaded a ZIP file...
Those articles were very informative! Heck, I never knew SPOOL was an acronym :) You might consider adding the articles to the sub-forum on this site. I'm sure others would find the info useful (it would be easy to find that way).
Tell me more about this 'unused gate' on the 1541...
In its first incarnation, I'll probably just stack 8 drives and let the C64 handle control using regular DOS commands and files. That way each unit can have its own drive to use not only for data input and output, but also as scratchpad memory. This would add a lot of flexibility to the kinds of routines you could run. (Manipulating large arrays on disk?)
If you used all 40 tracks without a BAM or sector headers, you could store, what, up to 192K of M/L for each drive, or 768 separate 256-byte M/L routines. That's a pretty big program. Of course, I'd also want to store input and output data on the same floppy, and I probably wouldn't abandon the standard DOS formatting unless I had to. Still, it's fun to contemplate.
I'm currently checking out various M/L routines to see which ones will fit in 1541 RAM. I'm especially interested in any that will do convoluted math on individual digits of long problems. Think: computing digits of PI, cryptography, fractals, etc. If you have any suggestions or sources for 6502 routines (other than 6502.org), let me know.
But here's another problem: You can only physically change the device number on a 1541 to 8, 9 , 10, or 11 by cutting pads or bending pins 15 & 16 on 6522/2. You can change it to a higher number in software, of course, but is there a relatively simple hardware hack for devices 12, 13, 14, & 15? I'm thinking it would be cool to eventually hack a retro rotary switch to each for device selection.
I've also heard it claimed that using a drive as unit 15 is unwise. Any idea why?
BTW, I also found the print spooling program in Abacus's 'Anatomy of the 1541' which was published in June of 1984, a year before there even WAS a C128!
ALSO, there are a few typos in the executables and text listings in the ZIP I uploaded. I haven't had time to fix them yet, but when I do I'll post here.
Quote from: airshipIf you have any suggestions or sources for 6502 routines (other than 6502.org), let me know.
Well, you could disassemble some demos to see how they perform their mathematical magic. :P
Before you do that, however, you might want to check out the math routines section of the C64 Codebase (http://codebase64.org/doku.php?id=base:6502_6510_maths) wiki.
I don't think there will be any problem fitting calculation routines for things like fractals even in the limited RAM of the 1541, unless you're trying to use something that relies on 4K of lookup tabes or something.
Thanks. I forgot about the C64 Codebase Wiki. There ought to be some innovative demo code there!
And even with 4K of lookup tables, you could always put the tables on disk and load them 254 bytes at a time...
Quote from: airshipAnd even with 4K of lookup tables, you could always put the tables on disk and load them 254 bytes at a time...
Well, if the purpose of the lookup table was to speed up calculations, that would kind of defeat the purpose. :P
In most cases, you'd probably do better with a routine that takes more cycles but doesn't require a large lookup table. Or use smaller tables if you can still get the required accuracy. It should be possible to do fractal calculations and even simplistic raytracers entirely in 1541 RAM, flushing your pixel buffer to disk (or sending it back to the C128) whenever you finish X number of pixels. Have each drive process different rows, and you could have some zippy little multiprocessor fun going there.
How about adapting KIM-I Microchess? It fits in 1K. By stripping out the screen display code, it should fit in 3 of the 4 buffers of the 1541, leaving one for DOS disk accesses. There's a version that uses an RS-232 terminal here ( http://6502.org/source/games/uchess/uchess.htm ) that could be used by replacing the RS-232 code with IEC serial communications calls.
(http://6502.org/source/games/uchess/c1.gif)
You could set up a tournament where the 1541s would play against each other simultaneously (4 ongoing games at a time) according to matches set up by the C64. The C64 UI could selectively display any game in real-time while the others continued in the background.
Shoot, with each drive actually playing chess, I wouldn't even care if the C64 had to act as traffic cop for them. My original idea was to be able to have them communicate directly. Maybe they still could, but... I mean, they'd be PLAYING CHESS!!! How cool is that?
In future versions, each 1541 could potentially learn from its mistakes by creating lookup tables on disk that said 'In the 303 games when the board looked exactly like it does now, when I made move zz-1, xy-3, or po-4 I usually lost, but when I made move xx-7 or pq-6 I usually won; pq-6 has a little better win rate, so that's what I'll do'.If one drive got so that it won most of the time, you could DUPLICATE its disk for each of the other drives so they would all start out just as good as each other again. Or you could come up with a C64 program that would integrate the experiences of ALL the drives on a regular basis, then create a new master disk for them all to start with.
You could even play human against any one of the drives. Or all of them, round-robin style.
Is that cool enough? :)
Hmm... for I/O, could you share between your real drive system and your 64HDD setup, so that instead of reading/writing floppies you could use the networked PC? Then you could relieve some of the I/O burden and focus on the power of having many 2Mhz processors at your disposal. Sure, it's not quite as cool as the pure approach, but would still be pretty nifty.
A couple of years ago I posed a question on c.s.cbm about using 1541's as a distributed computing grid with a C64 as the controller. I was told I was nuts and it would be useless. Now, I'd really like to see this chess idea to fruition.
BTW, I'd say let each drive log it's own learned patterns, then you can see what happens when drives with different experiences plan against each other. This would be a true learning super-computer as it would have far more realistic simulation of how humans learn.
I'd like to keep it pure CBM. There's just something so right about having the drives use their own floppies.
And they wouldn't even be doing that until the 'upgraded' version with lookup tables. In version 1.0, the C64 would load the drive runtime routine from drive 8 and send it over the serial bus to each drive in turn. Then it would set up tournament opponents and go into monitor and display mode. Not even the C64 would read or write to a drive after that. The 1541s would run MicroChess without drive or bus access until they had a move to transmit, or needed to input a move from their opponent. I don't know how long it takes for the 6502 to make a move in MicroChess, but I imagine it's long enough that the bus won't be too busy just moving a couple of bytes per drive each time a move is made.
Even in v2.0, reading and writing lookup tables on their own floppies wouldn't take up the serial bus, though it WOULD take up a buffer. With no reading or writing going on at all, we'd have the full 2K to play around with (plus usable ROM routines).
Hmmmm... If a drive is spending 1/2 of its time waiting for its opponent to make a move, why couldn't it play TWO games of chess at once? It could just play against itself but that wouldn't be nearly as much fun, I don't think, as playing another unit. Interesting...
How about 'multitasking chess'? Each 1541 would just be a generic chess player. The C64 would be the master controller for any number of ongoing games, be it one or a thousand. You could use one 1541 for as many individual unit numbers as you could configure. The C64 would keep a table of board setups for each game. As each 1541 made its move on its current game, the C64 would log it and change the board setup for that game and push that game on the 'move pending' stack. It would then send the board setup for the top game on the stack to that 1541 and tell it to run. Rinse. Repeat. I LIKE IT! :D
BYW, 1541s are 1MHz. ;)
Another idea, do this with 1581's instead of 1541's as they have a lot more storage and are a lot faster. Hell, get some CMD-HD drives involved as well!
Payton, Payton, Payton... the idea is to do this with creaky old hardware in a super limited environment. That would be CHEATING! :)
Well, 1581s wouldn't be cheating... they've got the Commodore name on them, after all. :P
EDIT: The true Commodore name, that is. We can't have the new Commodore Gaming PCs trying to muscle in. :D
Quote from: airshipTell me more about this 'unused gate' on the 1541...
On the original 1541s (this may be different for the 'C or 'II) there is a quad NAND gate UC7 and the first NAND gate (pins 1,2, and 3) is unused. The schematics show the inputs are both grounded and the output disconnected.
EditFurther examination reveals it is a NOR gate. Unfortunately the schematic I have is a low-res scan and many things are illegible.
/EditCut the input traces to ground, then route both to a VIA output line. Route the NOR output to the ATN line. In theory! For this to actually work, the NOR would need to have an open-collector output. I don't have a TTL data book handy so I don't know. In fact from the schematics, I can't tell if its 7402 or 7403
EditI believe it is a 7402 by reference to another schematic
/Edit. Looking at the schematics, it appears NOT to be open-collector, bummer!
You would probably want the C64/128 to fascillitate the IO since incorporating direct communication would require custom IO routines which would take a bit of RAM. At least 128 and probably 256 (or more) bytes. Of course this is just a guess based on fast-loader experience which is quite a bit different than the current application.
Well, my first step is to trim the C64 adaptation down to bare bones. I'm separating out the I/O routines so they can be relatively easily replaced with serial when I move it to the 1541s, plus I want the C64 version to co-exist with BASIC.
I could only find 56 relatively free zero page locations on the C64 (RS-232, cassette, etc.), and only one block of 16 contiguous bytes. I need two blocks of 16 bytes as the code is currently written, plus another 30 single-byte zero page locations. That's 62 bytes. So not only am I 6 bytes short, I'll have to split the backup board into two 8-byte chunks to get it shoehorned in there. I think I can put the backup board in main memory - its only used by one routine, I believe. But the main board HAS to be in zero page and it HAS to be 16 contiguous bytes. It's just used too often.
I can keep the code shorter if I just load the entire 1541 zero page with a M-W on each change of sides. I'm thinking I can read zero page from an idle drive, overlay the variables on it, and reload it back in on every move, with the new board, counters, etc., already in place. I'll probably run into some problems with that. If I do, I'll have to use multiple writes to zero page blocks to do the setup. This is cheating a bit, as it relies on the C64 to do the setup portion. My hope is that this approach will make the code short enough that I can keep a buffer open to let the drive actually act as a drive while playing chess. Otherwise, what's the point? :)
I want to keep the C64 version BASIC-compatible so it can run in the background while the BASIC interface program is running. That way you could have eight 1541s, the C64, AND a human all playing each other simultaneously.
I'm trying hard not to get started on the display/control/user interface program until I get Microchess working the way I want it to. My M/L is VERY rusty and I don't want to get drawn into the BASIC part or I'll never get the M/L done.
Uh-oh. I haven't even finished my first pass through the original Microchess code and I find this article on an IMPROVED version! Feature creep already!
http://www.atarimagazines.com/computeii/issue1/page19.php
Is the BASIC code going simply going to call the ML routine on the 64, or will the ML be running in the background via IRQ?
If BASIC simply SYS the code, you can use FAC, ARG, and TMPFAC. Thats over 15 bytes but its not all continous. Of course this is temporary ZP memory so save anything you need between SYS's someplace safe.
Thanks, but I've already got all of those. I need more!!! :(
I need every zero page location that's not used by system maintenance (i.e. if you use it the system hangs), screen display, keyboard input, or IEC communications. I think I have them all, but if you have any more insights, they'd be appreciated.
For the first pass, I'm going to use pure M/L, with Kernal calls for user I/O. That will be just human vs. Microchess. Once that works, I'll rewrite it to work in the drives. Last is getting a working version in M/L that will run behind the BASIC interface for the drives. Its got to run via IRQ. I don't want the BASIC program halting while the chess routine runs.
Why not develop it on the 128? At least on the 128 you can set up your ML with its own zero page. 256 contiguous bytes of zero page goodness for you to use. Then later on you can port it to the 64. For the 64 port, I'd recommend not worrying about sticking every program variable in zero page. Since your ultimate goal is to have it running in the background, which will make it slower than your drive-based version anyway, might as well stick some of your variables in main memory. Or, my personal suggestion would be not to have a 64 version at all, but only use the 64 as the gamesmaster. Code up something to keep track of statistics, let you peek in on games in progress on the drives, let human play against one or several drives, etc, and leave chess to your 1541s.
That's really all I wanted to do on the C64, have it run the system and not play chess at all. But since I'm developing the 1541 drive version there anyway, I thought, hey, why not keep a copy in the background to make one more player? You could even then use it a a stand-alone person-vs-computer program, though there's already a version of Microchess that does that. It's just a nice side effect.
Obviously I would love to do this on a C128, but a C64 is capable of doing it. Since I've got a half dozen idle C64s sitting around, I thought this way I could just stack them all up with a 1702 when it came time to test, without tying up my 128.
I've already thought that the really cool thing to do with a C128 would be to set up a bunch of 1K program spaces, each with its own zero page, and let them go at each other. Microchess makes a move about every 5 minutes on a 1MHz KIM-1. That's the same speed with 2 programs playing each other on a 2MHz C128. With 4, you'd run half-speed. With 8, 1/4 speed. Right? So you could play a complete chess tournament with 4 concurrent games, and one move (not each, but total) being made every 2.5 minutes. Heck, that's much faster than most human tournaments I've seen!
No matter HOW many microchess instances you had playing each other, you'd still get one move about every 2.5 minutes. So you could run, say, 96 instances playing 48 concurrent games, and still have room for a nice tournament master and board display program. Maybe even in BASIC. :)
RE: the idea of calculating Pi to an arbitrary number of places in a 1541 and writing it to disk...
It seems that GMTA. There's this thread on Google Answers from 2002:
http://local.google.com/answers/threadview?id=33189
In which a guy called googlebrain-ga posted this:
QuoteSomewhere, I have a disk with a program that caused a 1541 Disk Drive to calculate Pi, and write the data to an inserted disk. I was very bored that week. If I can find it (Even if I still have the disk, it'll be seriously old) I'll post the source here. It wasn't very long, but it was all ML (Obviously, since the drive didn't support any high level languages.
Needless to say, he never came back to post the code. Arrrrgh! I'd love to see what he did. Has anyone, anywhere ever heard of this? Did it make it into the wild? Or do you just think he's bragging?
Golan - do you know this guy? :)
Quote from: airshipGolan - do you know this guy? :)
You probably won't believe me but that program was written by Ken Kopin. I dropped him a line to see if he still has the code kicking around. I'll let you know.
I told you: Everybody. I've square danced twice in towns you've never even heard of. :P
Quote from: gklingerI told you: Everybody. I've square danced twice in towns you've never even heard of. :P
The Queen said she wants her slippers back.......
Lance
Quote from: adminThe Queen said she wants her slippers back.......
I told you about our liaison in confidence. Not cool, man. ;)
There's a reason I posted here, Golan. I would have been VERY surprised if you DIDN'T know him! :D
I heard back from Ken and he says that he no longer has the code and that it didn't work all that well to begin with (he didn't elaborate). So, who wants to take a crack at this? I would but I've got too many projects on the go and I'm on a new diet which precludes my having anything to do with pi. :)
I thought it was a cool idea when I came up with it independently (albeit 5 years AFTER he did!), and when I saw his post I got REALLY excited. But I lack the ML skills. I'm still struggling with adapting MicroChess for the 1541, and it's been months. :(
Well, it'll be a bloody miracle if I ever actually get any real work done on my 1541 MicroChess project, but with winter coming up, who knows? I might get inspired. So here's the plan:
C64/1541 Parallel Computer
PHASE I
Goal: IA, C64 control program communicates with a single 1541 and displays results; IB, 1541 plays MicroChess.
1x 1541
1x C64
1x C64 Control Program
1x 1541 MicroChess Program
PHASE II
Goal: IIA, C64 control program communicates with 8x 1541s and displays results; IIB, 1541s play MicroChess against each other.
8x 1541 Disk Drives (software address changes)
8x IEC drive cable wiring harness
PHASE III
Goal: Same as Phase II, but all hardware stripped down and in single case.
7x Stripped 1541 Disk Drive Controller boards (hardware modified to buss addresses 9-15)
Custom multiple drive board power supply
Drive board wiring harness
Custom Case
PHASE IV
Goal: IVA, C64 control program becomes general-purpose; IVB, 1541s given expanded memory & general-purpose software capability.
8x RAMBoard clones (8k)
8x custom 1541 ROMs (drive mech. control code removed, Kernal-type routines added)
Essentially, by the end of it all, the 1541s would have been converted into general-purpose 6502 single-board computers with 8k of RAM and custom 8K ROMs, with a C64 acting as a general-purpose control computer.
Personally, I will consider it a major success if I even get Phase I completed in my lifetime.
Sometimes I wish I weren't so inherently lazy. :(
I'm suprised you're still contemplating the "Chess Drives." I'm more suprised you haven't got Phase I complete. With MicroChess already written, I can only guess that the problem is communicating with the Commodore 64/128. My idea would be, after loading the code into drive RAM (and running any needed set-up), to issue a M-E command for the drive to execute a turn, then M-R the result. Take the result and M-W to a second drive and repeat withe the other drive (M-E with new data then M-R to get its result).
Of course this entails 2 drives and your Phase I only has 1 drive... if you insist on 1 drive then I think you'd need to put MicroChess in the 64/128 as well. I'd try it in VICE with 2 drives... your call.
I haven't analysed the MicroChess program (although I have had a glance or two at it). Anyway, my concern is that without some randomization routine, all the games would be exactly the same...
QuoteI'm surprised you're still contemplating the "Chess Drives." I'm more surprised you haven't got Phase I complete. With MicroChess already written, I can only guess that the problem is communicating with the Commodore 64/128.
Your assumption is wrong. My problems are (1) too much sick time this past year, and (2) inherent laziness. That's why I generally promote myself as an 'idea man'.
But I'm determined to get this done. My big problem is finding enough contiguous zero page locations for MicroChess in the 1541 memory map. The drive routines use a LOT of zero page locations. I think I can make the code fit in RAM easily enough, but even that will take some squeezing.
Plus my brain keeps wandering to things like user interface and storing tables on disk. I keep trying to push them out so I can get the nuts and bolts working. It'll happen this winter or I will quit this board in utter disgrace and live the life of a hermit.
I really want to be able to demo this at a Commodore show next year, if possible. (There, I've said it in public; no turning back now!)
QuoteMy idea would be, after loading the code into drive RAM (and running any needed set-up), to issue a M-E command for the drive to execute a turn, then M-R the result. Take the result and M-W to a second drive and repeat with the other drive (M-E with new data then M-R to get its result).
Exactly what I intend to do. But you can actually simulate this step by doing the read and write to the SAME drive. After all, it's just sitting idle waiting for a response anyway, right? :)
Re challenge #4: http://www.csbruce.com/~csbruce/cbm/transactor/v7/i2/p072.html
This article describes a ML routine, callable by SYS, that transfers the 40-column graphics screen to either the left or right side of the 80-column screen, and vice-versa.
Is there anything they DIDN'T do in the Transactor???
Edit: Like wise for #3: http://www.csbruce.com/~csbruce/cbm/transactor/v9/i1/p020.html
I swear I read all these articles once upon a time. I think I even put them into a book. Didn't I? So why don't I remember?!? ???
Believe it or not, I've finally got a clean source file that assembles into an executable C64 version of MicroChess on Merlin 128. It actually plays chess. Yea!
Next is to trim it down to the bare bones. I'm going to make it put its results into three memory locations I can PEEK in immediate mode, and make it read my input from two immediate POKEs. Once that works, I can easily translate that primitive I/O scheme into M-R and M-W commands for the 1541.
Should be easy to keep this trimmed version as my C64-player code for testing and, if I want, eventual incorporation into the final version.
Turns out there's also a command to make MicroChess switch sides. I can use that to make any drive play white or black, and even queue up drives to take the next available player position of either color. But that'll be a few versions down the line.
C'mon long, snowy Iowa winter! :)
Quote from: airship on September 04, 2008, 07:20 AM
Believe it or not, I've finally got a clean source file that assembles into an executable C64 version of MicroChess on Merlin 128. It actually plays chess. Yea!
Congratulations! :-)
Looking forward to the completed version,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug