CBM 610 (B128) IEC adapter

gsteemso · July 13, 2010, 11:13 PM

According to the Canonical List of Commodore Products on zimmers.net, the commodore 8" drives included the CBM 8060, 8061, 8062, 8280, and 8280 LP. All save the first were apparently dual drives.

carlsson · July 20, 2010, 12:01 AM

Quote from: Michau on July 04, 2010, 03:18 AMI have been playing with the kernal source code, and came up with a first revision.

Nice. I currently have my 610 next to me on the desk, so possibly I will be able to try your kernal in a short while.

carlsson · July 20, 2010, 02:49 AM

My hardware setup is as follows:

CBM 610-256K (which probably is known as a 620, although that model number is not official)
8250LP drive set as #8
2031 drive set as #9
uIEC/SD set as .. can't remember, but I think #9

The CBM 610 is equipped with Swedish characters, so the replacement kernel "screws up" the keymap (restores it to US layout).

I don't know if the two attachments were on purpose, but I tried both Kernels. They are slightly different, but work just as bad:

The IEEE communication locks up when the data channel appears to close, i.e. when I LOAD"$",8 it accesses the drive but locks at the READY prompt.

The IEC communication does nothing at all. Previously using Uz' routines, I managed to communicate somewhat with the uIEC/SD. I could of course try a good old 1541-II instead, but I'm not sure it would make any difference.

Then again I should install Uz' kernel or a cartridge version of it to ensure the hardware connection is as it should.

Conclusion is that neither of the recently posted binaries runs properly on my machine.

Michau · July 20, 2010, 02:59 AM

OK, thanks for the report. I will have my EPROM burner tomorrow so I will try it on a real 610.

carlsson · July 20, 2010, 03:49 AM

I still like the idea to make a cartridge with IEC routines that can be enabled when needed. In that case, almost everyone can enjoy it without opening their computers. Many may even have 24 pin ROMs installed which makes replacing a kernel even more difficult.

If you need spare cartridge boards for development, just send me a PM and I'll send some for postage costs.

Michau · July 20, 2010, 05:22 PM

You're right, a cartridge would not mess with a keyboard layout, NTSC settings and so on. It moght not be so easy, however, as the IEC kernal has for example a custom IRQ routine.

I can work on this. Please PM me postage rates to Poland for the cartridge.

Michau · July 22, 2010, 04:36 AM

I have created an updated Kernal and was able to burn it. My 610 boots OK and uses the IEEE drive well. However, IEC will indeed not work - I checked that my IEC status variable has wrong values (PEEK(1020)). This needs debugging.

The process of reassembling and burning a new EPROM each time is rather cumbersome. I think for debugging purposes, it will be better to create a simple file that is to be loaded at $0400 with the routines. This way it will be possible to modify it without wasting EPROMs.

I ordered a nullmodem cable so I'm hoping to connect my PC via RS-232C to be able to upload files easily.

Steve Gray · July 22, 2010, 12:41 PM

Quote from: Michau on July 22, 2010, 04:36 AM
I have created an updated Kernal and was able to burn it. My 610 boots OK and uses the IEEE drive well. However, IEC will indeed not work - I checked that my IEC status variable has wrong values (PEEK(1020)). This needs debugging.

The process of reassembling and burning a new EPROM each time is rather cumbersome. I think for debugging purposes, it will be better to create a simple file that is to be loaded at $0400 with the routines. This way it will be possible to modify it without wasting EPROMs.

I ordered a nullmodem cable so I'm hoping to connect my PC via RS-232C to be able to upload files easily.

Yes, we discussed development options earlier in the thread. You might consider Jim Brain's ROM-el. I suppose using $0F0400 ram could work but then you'd need to transfer the PRG and LOAD it... One other option might be CBMLINK. I believe it can load to memory from PC and execute it. You will need to load in the CBMLINK client but at least you won't have to continually transfer the new code to disk. I've never tried it, so if you get it working let us know.

Steve

Edit: CBMLINK also uses $0400 memory so maybe that's not going to work... I think Anders mentioned putting CBMLINK on a cartridge so if you get a cartridge from him that might be an option. I'm still convinced the cartridge way would be best for people who don't have the ability to burn roms and build adapters. A cartridge could hold upto 24K of ROM so we could put all kinds of things on there... JiffyDOS, wedge, cbmlink, extended monitor, sidplayer (wishfull thinking)...

Michau · July 22, 2010, 05:40 PM

Yes, the cartridge is the best option for final distribution, but not for development (constantly burning new EPROMs...). That's why my idea is to develop and debug the IEC code in RAM at $0400. First I would simply copy the IEC routines and allow for enabling/disabling them via a SYS call. Then I would debug my IEEE/IEC multiplexer code to have it work properly. After that, the code can be put on cartridge. The rest of cartridge development (initialization code, etc.) can be done in VICE.

I would write a simple BASIC program that downloads the code from PC via RS-232. Should be easy, if the cable works properly

carlsson · July 23, 2010, 06:30 AM

For what it is worth, earlier this week I made myself a cartridge with the C2N232 client code. As per earlier experiences, I find I need to execute two SYS:es to start it: SYS 24576 to start the cartridge and SYS 1024 to start the client. Previously when I tried to JMP $0400 from within the cartridge code, it locked up the machine IIRC. I also tried to add an autostarting CBM header, but it crashed the computer upon startup and threw me into the TIM monitor.

But I agree with Michau, it is a tedious process to burn and erase EPROMs all the time, even if they are placed on a cartridge board. In particular since VICE seems only to have partitial support for this system. For example, has anyone managed to get mounting of a cartridge image to work in VICE? Or for that matter, get either the built-in TIM monitor or VICE's own monitor to recognize what should be in the memory slot allocated to a cartridge? So far I failed both.

Michau · July 23, 2010, 05:42 PM

I just fired VICE, put the moni.bin image from Uz' archive at $4000 and it works (SYS 16384 properly starts the monitor).

carlsson · July 23, 2010, 08:50 PM

Hm, I gotta try again. A .bin file means it lacks the two byte load address? Based on my previous experience with VIC-20 cartridge emulation, it usually didn't matter if it is a 8192 byte .bin or a 8194 byte .prg file, VICE would detect either but perhaps when you configure a ROM set it must not have load addresses or it won't attach at all.

Michau · July 23, 2010, 11:48 PM

Yes, a .bin ROM image does not have the two-byte load address.

Michau · July 31, 2010, 04:57 AM

OK, I got my 1581 today and after some twiddling the Uz' kernal does work! I still don't have the RS-232 cable yet, but at least now I know that IEC works.

Michau · September 18, 2010, 02:10 AM

I have a first version working

Right now it's a loadable code that is placed at $F0400. SYS 1024 disables IEC, SYS 1027 enables it. Tested with 8050 and 1581 and works great. I will out it on a cartridge and post a BIN file here shortly.

carlsson · September 20, 2010, 06:15 PM

Great improvement, looking forward for the results!

Michau · September 24, 2010, 07:17 PM

This is the cartridge image. It goes into $F6000, that is the right slot in Carlsson's cartridges

Usage is very straightforward:
SYS 24586 - disable IEC
SYS 24589 - enable IEC

This is what I would call a manual solution - every time you need to use a device on a different bus, you need to switch the routines via a SYS call. So it's not possible to use an IEC and IEEE drive at the same time. But besides that, it works great

I will work now on an automatic solution - routines that dynamically detect which device is of which type. This requires some amount of work, so I can't promise a deadline. But I have n idea how this would be done.

Steve Gray · September 24, 2010, 11:43 PM

Good start. I will try this on the weekend.

Steve

Steve Gray · September 30, 2010, 06:11 AM

It seems to work fine for me too!

Can you make it autostart and display a simple message on how to activate/deactivate it? Oh, and perhaps a version# as well?

Keep up the good work!

Steve

PS: I also burned the VT-52 emulator to install in the left socket. Interestingly, it seems to autostart but I can't figure out how. It hooks into the system so that pressing ESC-? starts the emulator. Perhaps you can look into how that works and implement something similar...

Michau · September 30, 2010, 07:08 PM

Yes, I will be working on the autostart mode. I will make it so that it replaces the standard CBM-II initialization routine (with faster RAM test

etc.), switches the IEC routines and jumps to BASIC.

But first I want to make the code auto-detect the type of attached device, so we would not need to switch in on and off constantly. I was making some tests yesterday and debugging the code, it's so much easier when I can download it into RAM via the cable

carlsson · September 30, 2010, 09:37 PM

Cool, I had almost given up on autostarting CBM-II cartridges...

Michau · October 01, 2010, 04:37 AM

Autostarting is tricky if you want the machine to boot normally, but have just some parameters (i.e. routine vectors) changed. For example, the vector initialization (RESTOR) is called from the BASIC initialization module, which basically would overwrite the IEC routines on every reset.

So you actually need to rewrite a portion of kernal initialization code, then a portion of BASIC initialization code. What is worse, BASIC routine addresses are different on 128/256 models, and also on the P model. So the cartridge needs to figure our which BASIC is installed and make appropriate calls.

Steve Gray · October 01, 2010, 06:13 AM

Well, the majority of machines made are B128/610 and all the commercial software (not much) is written for those machines. I'd say you could ignore the 256 models. Similarly, very few P machines were made and they also run at 1MHz so you'd probably have to adjust all the timing as well. If you can easily support all modes that would be fantastic, but it's probably not worth the extra effort.

Concentrate on 128K B-series, autostart, and an easy way to select/change interfaces.

Some ideas for discussion:

A) Default to IEC (since the cartridge is installed that's probably why it's there)
B) Use SYS to select interface (simple, but would not allow mixed access)
C) Use one byte in zero page as "device flag" for device 8 to 15 - if bit is 0 then IEC, if 1 then IEEE (I suggest using 00001111 as the default flag)
D) Use WEDGE command, ie: ">IEC n" or ">IEEE n" sets device flag
E) How to handle two devices with same ID on different interfaces? Perhaps re-map IDs. Device 8 to 11 would be on the IEC bus as normal, and devices 12-15 would be on the IEEE bus. Device 12 would remap to IEEE device 8, 13 to 9, 14 to 10, and 15 to 11. This way no messing with switches or device jumpers would be required. Perhaps this behaviour could be toggled with a wedge command, ie ">REMAP ON/OFF"

Steve

Michau · October 01, 2010, 07:30 AM

Well, I must support the B256, since I have myself upgraded my 610 to 256kB RAM and BASIC 256

But I guess that the P500 could easily be omitted.

I want to make the interface so that no switching/enabling/disabling is required. That is, it should work totally automatically. First I thought of making a device mask just like you suggested. But now I think it can be made easier.

Every bus transmission must begin with TALK or LISTEN. So with these operations, I will call IEEE routines first. If the device responds, I will set the flag "Current device is IEEE", and all further operations will use IEEE routines until next TALK/LISTEN. If not, I will call the IEC routine. If the device responds, I will set the flag "Current device is IEC" and all further oeprations will use IEC routines. If no device responds on either bus, I will set the status variable accordingly and exit.

ID remapping is a very neat idea (although my 1581 has nice switches to select the device number

). But I would need to learn how to write BASIC wedges

and dedicate some RAM area for the remapping map. But it is definitely worth looking into.

Steve Gray · October 02, 2010, 03:01 AM

If anyone is interested, I just posted the schematics to a CBM-II RAM/EPROM cartridge that was loaned to me. It might make development easier, but you'd have to build one first of course...

http://www.6502.org/users/sjgray/computer/cbm2/cbm2-24k-schematic.jpg

You could subsitute a NVRAM chip like the DALAS DS1225 to make an updateable cartridge!

Steve