Last week, I came across Ullrich von Bassewitz' adapter for the CBM-II series computer, which lets one attach a 1541 floppy drive to the otheriwse unused cassette port. It requires installing a custom Kernel though.
http://zimmers.net/anonftp/pub/cbm/b/kernal610-new.zip
The interface is very simple; just the two connectors, a few wires and two small (68 and 82 ohm) resistors. I wired up one last Friday and tried. It works very well:
(http://www.cbm.sfks.se/pics/610-iec-adapter1.jpg)
The actual adapter:
(http://www.cbm.sfks.se/pics/610-iec-adapter2.jpg)
Then I soldered on the +5V lead to Jim Brain's uIEC interface and plugged in the cable. Suddenly I have one more Commodore computer working with the uIEC.
Steve Gray and me have discussed the possibility to extract Uz' driver code to a cartridge image, as I have access to a small surplus of B128 cartridges fitted with two socketed 2764 each, for a total of 16K. If we advance with this, I think at least a DOS wedge would be required. To implement JiffyDOS for the B128 however may be a bit too advanced...
As a side note, it was speculated whether this kind of adapter would work with PETs, and of course VIC-20 and C64/128 if you want an additional IEC port. It is just a matter of writing/adapting the driver code. I would suppose someone in time has already done this for the PET? In particular as most PETs have room for utility ROM expansion, it would be very handy to have a driver to let you connect 1541 like drives.
QuoteThe interface is very simple; just the two connectors, a few wires and two small (68 and 82 ohm) resistors. I wired up one last Friday and tried. It works very well:
Very interesting. Do you have a wiring diagram with the connector pin numbers?
By the way, I like that first picture. It's a good feeling to know I'm not alone in the world. :)
Dan...
Anders,
I haven't had the chance to build the interface yet, but in the mean time... I assume the new kernal allows IEC only and replaces the IEEE. If we get the code working in a cartridge perhaps we can select which interface to use somehow. I'm thinking we could check for a key (like the C= key) on startup and allow selection of IEC or IEEE.
Are there any commented disassemblies of Jiffy DOS? It shouldn't be too hard to merge JiffyDOS into the B kernal.
On the BASIC 4 machines I've never needed a DOS wedge. Plus the B-series machines already have programmable function keys, so what wedge functions would be useful ?
Steve
QuoteVery interesting. Do you have a wiring diagram with the connector pin numbers?
Never mind. I should have looked at the kernal610-new.zip file first. The wiring diagram is in the file.
Dan...
While I actually didn't try to plug in an IEEE drive into the computer, I believe you're correct. Since Commodore left out tape routines in the first place due to being short of ROM space, it would be a miracle if Uz' could squeeze IEC routines into the same 8K while keeping the IEEE routines in place.
I agree that a cartridge would allow one to enable/disable the adapter support, given that the B-series machines use low 1K pointers much like other Commodore computers to steer various kernel calls to different locations.
Quote from: Steve Gray on April 13, 2009, 10:53 PMwhat wedge functions would be useful ?
When used with a memory card device like the uIEC, the @CD command and others are quite frequently used to switch to a new directory. Without a wedge, you have to OPEN1,8,15,"CD:nnn" all the time. $ to read directory contents can also be useful instead of LOAD"$",8. I'm sure there already exists e.g. a 8250 wedge for the 610/710 machines, just that I haven't looked around. Besides, if the actual IEC routines only are 1-2K and we have at least 8K cartridge space to work with (16K if we feel adventurous), the other space could just as well be used for some goodies like a wedge, possibly SJLOAD compatibility unless a full JiffyDOS implementation can be had.
But yes, it is much easier to chat on a forum than get down to the actual coding... ;-)
Dan: Good luck building the adapter. It was rather straightforward. Right now you'll need an EPROM programmer and replace the Kernel chip to use it. My CBM 610 was already modified for Swedish keyboard so it has adapters from 24-pin ROMs to 28-pin 2764 EPROMs. It made the change of Kernel very simple. If your B128 machine is original, you may find actual ROMs inside that would require an EPROM adapter. If you're really unlucky, the chips may even be soldered so the cartridge solution (not yet realized) would be the only feasible way to complete the task.
QuoteDan: Good luck building the adapter. It was rather straightforward. Right now you'll need an EPROM programmer and replace the Kernel chip to use it. My CBM 610 was already modified for Swedish keyboard so it has adapters from 24-pin ROMs to 28-pin 2764 EPROMs. It made the change of Kernel very simple. If your B128 machine is original, you may find actual ROMs inside that would require an EPROM adapter. If you're really unlucky, the chips may even be soldered so the cartridge solution (not yet realized) would be the only feasible way to complete the task.
Anders,
I don't have a CBM 610, I use a C128.
I'm curious about how it's connected and I thought I could go through to Kernal code to see how the data is transferred.
I have been looking for a way to connect the two printers I use on my system setup.
I have three drives connected to the serial bus (1541, 1571 and 1581). To operate the printer(s), I have to remove two of the drives because of excessive load on the serial bus.
If I can find a way to use the adapter as an extra serial bus, I can use it for the printers.
Dan...
Ah, I see. If I understand correctly, the regular IEC port is handled by CIA 6526 #2, data port A while the cassette port is controlled by the CPU itself with an IRQ flag on CIA #1? That probably would be the difference, to add one or more devices without putting more strain to the CIA chip.
QuoteThat probably would be the difference, to add one or more devices without putting more strain to the CIA chip.
Yes, that is the idea. But, it will have to wait until winter. It's fishing season now.
Dan...
Quote from: megabit on April 14, 2009, 04:07 AM
I have been looking for a way to connect the two printers I use on my system setup.
I have three drives connected to the serial bus (1541, 1571 and 1581). To operate the printer(s), I have to remove two of the drives because of excessive load on the serial bus.
Interesting. On my C128 setup, I have two 1571s, a 64HDD, a uIEC, and a serial printer. All work just fine, though I admit I seldom (maybe never?) have them all running at the same time. I've got the two 1571s in series, but everything is plugged into a Quadport, including the origin of the 1571 chain. I don't know if that makes a difference; I've always kind of assumed that internally the Quadport is wired in series, though I suppose it could be parallel.
Quote from: megabit on May 05, 2009, 09:43 PM
But, it will have to wait until winter. It's fishing season now.
If we could just get Dan to give up fishing, we'd get a lot more work out of him. :)
QuoteIf we could just get Dan to give up fishing, we'd get a lot more work out of him.
Now you sound like my wife. :laugh:
Dan...
Quote from: carlsson on April 13, 2009, 08:44 PM
Last week, I came across Ullrich von Bassewitz' adapter for the CBM-II series computer, which lets one attach a 1541 floppy drive to the otheriwse unused cassette port. It requires installing a custom Kernel though.
http://zimmers.net/anonftp/pub/cbm/b/kernal610-new.zip
The interface is very simple; just the two connectors, a few wires and two small (68 and 82 ohm) resistors. I wired up one last Friday and tried.
Steve Gray and me have discussed the possibility to extract Uz' driver code to a cartridge image, as I have access to a small surplus of B128 cartridges fitted with two socketed 2764 each, for a total of 16K. If we advance with this, I think at least a DOS wedge would be required. To implement JiffyDOS for the B128 however may be a bit too advanced...
As a side note, it was speculated whether this kind of adapter would work with PETs, and of course VIC-20 and C64/128 if you want an additional IEC port. It is just a matter of writing/adapting the driver code. I would suppose someone in time has already done this for the PET? In particular as most PETs have room for utility ROM expansion, it would be very handy to have a driver to let you connect 1541 like drives.
Well, I finally got my new eprom programmer and have burned my first eprom; the new IEC kernal. I guess it's time to build the cassette interface and give it a try. Then, we'll see about working on a cartridge version that can toggle between IEC and IEEE. I think I'll put aside jiffydos until I get at least that working.
Steve
Yay! I had forgotten about that, although admittingly it isn't on the top of my priority list. On the mailing list, Uz mentioned the IEC routines came from the Protext cartridge, whether that was a CBM-II product or some other Commodore computer. There is a cartridge called ProfiText mapping in at $2000. It might be worth disassembling to see if the same routines exist in that binary, and perhaps even easier to extract from.
http://zimmers.net/anonftp/pub/cbm/firmware/computers/b/index.html
Quote from: carlsson on May 22, 2009, 09:35 PM
Yay! I had forgotten about that, although admittingly it isn't on the top of my priority list. On the mailing list, Uz mentioned the IEC routines came from the Protext cartridge, whether that was a CBM-II product or some other Commodore computer. There is a cartridge called ProfiText mapping in at $2000. It might be worth disassembling to see if the same routines exist in that binary, and perhaps even easier to extract from.
http://zimmers.net/anonftp/pub/cbm/firmware/computers/b/index.html
Well, I plugged the ROM in and it boots, so that's a start. However, my monitor is not displaying the screen properly. I think the new kernal ROM is for PAL... I need NTSC. Anyway, not a big problem. Cable is still not built but I decided to take a look at the source, and I'm a little lost as it's all in German ;-) . So I got looking around UZ's site and I see a monitor ROM called "moni610" which resides at $2000 and ALSO includes the IEC routines! Great! So off to burn it and try it out.... oh oh, no more blank eproms... this could be what we're looking for but unfortunately I can't try it until I get a new supply of chips... care to take a look Anders?
ftp://ftp.musoftware.de/pub/uz/cbm610/moni610.zip
Steve
Nice find! The Moni610 package exists on Zimmers too, I just didn't register it would run as a cartridge. I'll have a look later, whether it will be today or in a week.
I dumped the EPROMs on two demo cartridges. From a brief look, they look quite the same. If anyone wants to have a look, grab 'em here: http://www.cbm.sfks.se/files/cbm610-carts.zip
I read in the CBM 500/600/700 User's Guide (which I've planned to scan, unless anyone has done that before) that the cartridge port pinout is the following:
Pin Type | Pin Type
1 A0 | A BD0
2 A1 | B BD1
3 A2 | C BD2
4 A3 | D BD3
5 A4 | E BD4
6 A5 | F BD5
7 A6 | H BD6
8 A7 | J BD7
9 A8 | K GND
10 A9 | L GND
11 A10 | M SR/W
12 A11 | N S02
13 A12 | P NOT CSBANK1
14 +5V | R NOT CSBANK2
15 +5V | S NOT CSBANK3
This pinout is by the way pretty identical to the CBM 500, only that pins P-S are not marked with NOT signs.
Anyway I burned an EPROM of the Moni610. Through trial and error I have managed to map it to $4000 just like the source code suggests and at least start the monitor. However it seems the IEC routines need to be stored into another 8K EPROM mapped to $6000. The source code includes those routines, so it is just a matter of re-assembling it to generate a 16K binary split onto two 2764 chips. I'll try that some other day. Once that works, we can consider whether to leave it as it is or perhaps put something even better than an advanced machine code monitor into the first 8K.
However I don't yet know how to enable the IEC routines, if those are included in that 8K binary that is.
Anders,
I looked at the code again. In the "moni.src" file there is an include for the serial routines ("serbus.inc") at the end of the file. In the "InitMon" routine is a call to "SerBusInit" and in that a call to "SerBusVecInit". I assume that once you get into the monitor the serial routines will work. Did you try?
Some simple changes will be to autostart the cartridge and put a small jump table at the beginning to switch from IEC to IEEE by changing the vectors.
I ordered some more EPROMs this morning so when they arrive I will give it a try. I guess i should get to work building the interface cable! ;-)
Steve
Actually I was wrong last night. The IEC routines already are included in the 8K binary. The reference to $6000 says where the ROM image should end, i.e. fill up to 8192 bytes.
The reason why I didn't get much action was because I tried with my uIEC which is set to device 9. There is a command UNIT in the machine code monitor. It takes a two digit decimal number, i.e. "UNIT 09" to switch the device number.
I can now read directories and hopefully load files from the IEC unit inside the monitor. However upon exit, the routines are disabled. I'll try later to put together a subset of the routines which at least allows one to SYS the IEC routines into place and back. Autostart might be nice, but so far I haven't seen any B-series cartridge implementing autostart. I read yesterday briefly what it takes to get it to work, so I suppose it is technically possible...
Quote from: carlsson on May 26, 2009, 05:25 AM
Actually I was wrong last night. The IEC routines already are included in the 8K binary. The reference to $6000 says where the ROM image should end, i.e. fill up to 8192 bytes.
The reason why I didn't get much action was because I tried with my uIEC which is set to device 9. There is a command UNIT in the machine code monitor. It takes a two digit decimal number, i.e. "UNIT 09" to switch the device number.
I can now read directories and hopefully load files from the IEC unit inside the monitor. However upon exit, the routines are disabled. I'll try later to put together a subset of the routines which at least allows one to SYS the IEC routines into place and back. Autostart might be nice, but so far I haven't seen any B-series cartridge implementing autostart. I read yesterday briefly what it takes to get it to work, so I suppose it is technically possible...
It appears that the monitor "exit" command does a call to the 'warm-start' vector, which reset the vectors back to normal. You could remove the call easily, or just put an easy jmp to "SerBusVecInit", or add "IEEE" and "IEC" commands to the monitor to select which to use. To autostart a cartridge you need the "CBMx" string at the start of the cartridge, where 'x' is the first digit of the cartridge start address (in this case '4').
[EDIT:] If you remove the '.RES' command in the source you'll see that the monitor and the IEC routines only take about 4K so there's lots of room for additions before filling up an 8k rom.
I hope my EPROMS arrive soon!...
Steve
I wonder if there is any way to use the emulator for development purposes. While it won't have the hardware support for an IEC unit, we know that code already works so it is more a matter that the computer won't crash in the middle of operation. Otherwise it will be quite cumbersome to program and erase EPROMs all the time, even if one has a cache of 5-10 chips to recyle.
Quote from: carlsson on May 26, 2009, 08:56 AM
I wonder if there is any way to use the emulator for development purposes. While it won't have the hardware support for an IEC unit, we know that code already works so it is more a matter that the computer won't crash in the middle of operation. Otherwise it will be quite cumbersome to program and erase EPROMs all the time, even if one has a cache of 5-10 chips to recyle.
Perhaps one of the cartridges can be modified to have RAM installed?.... battery backed would be even better ;-)
Steve
Even with a battery-backed RAM expansion, wouldn't it be kind of a chicken and egg problem? I have the following accessories:
* 2031 drive which is read compatible with a 1541 + XM1541 cable to write such floppy disks
* C2N232I which currently won't work with the B-series due to their lack of tape routines
* uIEC/SD which of course I'll connect to the IEC port once the drivers are installed
I haven't considered cbmlink/prlink, which might be the best solution in a development process given that it works on the B-series?
Anyway I read somewhere that machine code programs are best run in bank 15, due to the Kernel is accessible only in that bank. However I think the amount of system RAM in bank 15 is very low so therefore your suggestion about a memory expansion might come handy.
Alternatively the routines might be possible to rewrite to execute in another bank and then switch before every possible Kernel call. It would allow anyone to load the IEC program from e.g. an IEEE floppy drive.
Brian Lyons has made a couple of custom VIC-20 cartridges which contain a static/non-volatile 8K RAM chip. According to the manufacturer those chips should hold their content for 100 years or so. The good part is of course they're writable. My original idea of use would be to store highscore data from a game on the cartridge, but I realize the same kind of chip could have development purposes too, e.g. the kind of RAM chip you just described. The chicken and egg would still be there, just that once programmed the egg stays in place.
I was thinking of the RAM cartridge for development. It would make testing code much easier without needing to burn an EPROM all the time. I know there existed an internal 24K ram expansion board for the B-series that goes in BANK 15, but I haven't been able to find one. I know one guy with a 1MB expansion board but I think that expands the OTHER banks. If we could get RAM in bank 15 where the cartridge normally resides we could develop easily then when it's finished we burn an eprom.
I use CBMLink and a B128 to make D80/D81 images of my B-series and SuperPET disks in conjunction with my CBMXfer program.
Yes, there is minimal RAM in BANK 15 and coding is easier in BANK 15. There are special 'transfer routines' that can be used to access the kernal from any bank. They are located in ROM at $FE9D. Jim Butterfield wrote a nice article in transactor (July'83, Page 60) on how it works. Theoretically this should work for the IEC routines. However, I think one of the reasons for having IEC routines is for those who don't have an IEEE drive, since they are harder to get these days. Therefore, a ROM solution is best.
Enough typing... I'm off to build a cable ;-)
EDIT: I just looked and there is an 8K x 8 static NV RAM that is pin compatible with the 2764 and would drop right into a cartridge! It also has a real-time clock. Dallas Semiconductor DS1225. I think all we would need is to hook up the R/W line, perhaps with a switch to write-protect it. I've ordered 4 to play with. They could come in handy for other projects too.
Steve
Well, nothing seem to go my way... i can't seem to find the proper resistors in my electronics junkbox.. guess I'll have to buy some, unless other values will work.
Some more thoughts while I'm waiting for parts to arrive.
If you are familar with the "Batteries Included" BUSCARD (for the C64) it has dip switches to select which device is IEEE and which is IEC. So, perhaps a virtual dipswitch would be cool... we allow the user to do the same thing lets say by typing ">IEC 10" or ">IEEE 9" (fictional wedge commands) and then direct the routines to the proper vectors. This way we can have both interfaces active at the same time. The ">UNIT xx" command can set the "default" unit number. Not sure if this will all be doable for "outside" the monitor.
Steve
My EPROMS arrived (30 of them!-2764's) and so did my DS1225's. I looked at the demo cartridge PCB and I may need to cut some traces for the DS1225 to work, plus wire up the R/W line. It's 11pm here so it'll have to wait for tomorrow.
I did burn one EPROM with the MON610 bin, which seems to work ok. Haven't got my resisters yet so still no cable... tune in again for the next update ;-)
Steve
I have a local store selling assorted electronics surplus. Most of the time the bags contain odd value components but sometimes I can get a few usable resistors, connectors and so on out of it. There is another store with a bigger selection (also more expensive) but they only are open a few hours a day so I never get the chance to go there.
I suppose you have the connectors for cassette and IEC DIN available though? Whenever I find some spare time to look into this again, I'll let you know.
Quote from: carlsson on June 08, 2009, 06:29 PM
I have a local store selling assorted electronics surplus. Most of the time the bags contain odd value components but sometimes I can get a few usable resistors, connectors and so on out of it. There is another store with a bigger selection (also more expensive) but they only are open a few hours a day so I never get the chance to go there.
I suppose you have the connectors for cassette and IEC DIN available though? Whenever I find some spare time to look into this again, I'll let you know.
I have a bulk pack of resisters on order. 2500 from Hong kong for $10 plus a couple bucks shipping. figure that should hold me for a while. Yes, I have the connectors. I borrowed a nice cassette connector from an old c2n unit, and I'm going the male IEC route so it will be a single cable solution totally enclosed for a nice finished look...
BTW, I had an old 8k x 8 static ram chip that is 2764 compatible which I tried wiring up. I cut the ground-link at pin 27 and wired it up to the R/W line but no luck. I'm wondering if it needs the S02 and SR/W lines 'AND'ed to get it to work?... That's how the bank15 ram is connected.
My Dalas 1225 chips arrived but I haven't tried them yet.. last few days have been busy.
Steve
Update... I have built the cable and tested the moni610 cart and it is working. I was able to get a directory of a disk in my MSD-SD2 drive (using the IEC cable of course). Weird though, I used UNIT 09 and tried DIR and got an error 5 as expected but when I entered UNIT 08 to go back it wouldn't get a directory again, giving me error 2. Reseting and entering the monitor again worked fine. Not sure why the UNIT command would cause problems.
Anyway, next step is to try to get the 8K NVRAM working so I can do some development, otherwise i'll probably end up wasting many eproms....
Anyone know where I can find source code for a good DOS wedge?
Steve
I'm starting to look at the code. With the original moni610 rom I found you can activate the serial routines in basic by typing: sys 19174
I did notice that a directory listing takes longer from basic than from inside the monitor...
Still, my goal is to make something a little friendlier and with some extra features. I downloaded something called "util 700" and it resides at $6000. Its a bunch of utilities for basic but it's in german. Anyway, I have both installed in one cartridge to play with for now.
Steve
Keep up the good work! I don't have anything new to add, other than I picked up yet another bunch of cartridge boards of which I believe some could come to good use if more owners of the B-series computers want to enhance them with IEC support.
As a side note, yesterday I found another BOX full of CBM-II series cartridge boards. Some populated with 2764's, some bare. I don't know if they'll all work or which memory address they will map into, but I can go through them later.
That is saying, if anyone needs a few boards for experiments or perhaps making their own IEC cartridge, just let me know. It isn't like they're rare or anything, just that I doubt anyone produces new cartridge boards today.
Anders, I could use a few boards to play with.
Steve
Did we make any progress in putting the IEC routines into a cartridge, ideally keeping the IEEE interface/devices enabled? A few weeks ago I noticed my VIC-20 Dams IEEE-488 interface (http://www.cbm.sfks.se/pics/vic-dams-ieee.jpg) actually only grabs #8 for IEEE and allows IEC access to devices #9 and so on. Or perhaps it even listens to the IEEE drive connected, so if my 8250LP was set up to be #9, it would allow access to a 1541 as #8. If those routines for the CBM-II can work in a similar way, it would be great. Of course I could try to dump the 2532 EPROM inside my VIC interface if one needs inspiration.
On a side note, I'm considering putting the C2N232 loader for the CBM-II onto a cartridge. As you know the C2N232 connects to the same cassette port as Ullrich's IEC adapter does, and will need a loader/patch to be useable. Instead of loading the 444 bytes long file from disk, I imagine one could put it on a cartridge and SYS to start unless it can be made auto booting. It sounds like a waste of cartridge but I still have enough boards and EPROMs to make it worthwhile. Perhaps in the future even those routines (C2N232 and IEC) could be hosted on the same cartridge and one chooses which type of device to enable.
And yes, I know I could wire up a serial cable to the 610 but I still need the loader. Actually a 8K cartridge should have enough space to host support for all possible interfaces that can be connected to a CBM-II, but it is currently of mostly academic interest.
Hi Anders,
No progress yet. Now that xmas season has passed I hope to get back to the project. There seems to be renewed interest in IEEE interface stuff (1541 IEEE conversion, XS-1541, uIEC IEEE)... I picked up a uIEC at the World of Commodore show (thanks Jim!) and this will give me incentive to get the IEC going on the CBM-II's. Of course, any help is appreciated.
Steve
Yep, I will begin with trying to execute some code from a cartridge.
I Have made an alternative firmware for the XS-1541: IEEE2IEC (http://ieee2iec.t-winkler.net/)
You can attach any IEC drive from your commodore computer. It works as a bridge and transforms all command at low level (TALK, LISTEN, UNTALK, UNLISTEN, IECIN, IEOUT). Source code for Atmel AVR644 is inluded.
Quote from: carlsson on January 05, 2010, 07:51 AMYep, I will begin with trying to execute some code from a cartridge.
Aha! In VICE, cartridges are attached in the ROM settings dialog, not from a menu option. 8)
In the mean time, I learned the syntax for the BLOAD command. I found that my copy of the User's Guide contains typos which don't exist in the B Series User's Guide uploaded to Bombjack.
To load a file to bank 15, $6000 type BLOAD"file",D0 ON U8,B15,P24576
In any case, no matter what I attach in the ROM/cartridge dialogue, it seems nothing shows up neither in the internal CBM-II monitor nor in VICE's external one. Very strange and frustrating.
Actually my real question is I read this German document (http://zimmers.net/anonftp/pub/cbm/b/documents/de/600.txt) which near the end describes how to set up the cartridge header. I'm not sure I understand how it should look like, but this is what I tried:
org $6000
.byte $80,$60,$0f,$80,$60,$0f ; rem both cold and warm start at $F6080
.byte "c",$c2,$cd,"6"
org $6080
... program happens I realize $F6006 can contain $80 + "c" if the computer should use the regular Kernal initialization. Perhaps it should be $0C though, and thus the last byte should in this case be $06?
Furthermore, do I get the first two address pointers correct? I figure we still deal with little endians but the address seems to be a 20 bit one which makes me think the bank number is the last in sequence.
The code should be "CBMx", where x is the high-nibble of the address. with $30 added (to make it numeric).
On the B-series, cartridges could be at $2000, $4000, or $6000 so, $32, $34 and $36 or:
CBM2
CBM4
CBM6
In reality, the kernal routine looks at every $x000 page in Bank 15 (where x is 1 to F) for the autostart signature, so you could have an internal expansion ROM somewhere and autostart it as well, or have the signature in the middle of your rom somewhere. If no signature is found then $E000 is used (which will jump to $EE09 which is the ML monitor). Cartridges are cold started at $x000.
I looked at code in the kernal at address $F997. The autostart code is at $F9AA. The Autostart signature is at $F995/6= "BM", and the "C" is only checked for it's SIGN (bit 7) as a flag to initialize kernal, as you indicated.
The autostart routine only checks bank F and only jumps into code in bank F.
So... assuming cartridge at $6000, start of code at $6080:
$6000= $80 (Start of program LO)
$6001= $60 (Start of program HI)
$6002= ?
$6003= ?
$6004= ?
$6005= ?
$6006= $C3 "C" (or clear bit 7 to bypass kernal initialization)
$6007= $C2 "B"
$6008= $CD "M"
$6009= $36 "6"
...
$6080= Start of Program
I think $6002-6005 are reserved to be compatible with BASIC ROM. The kernal will set the restart vector at $03F8 to point to the start of the rom at $x000. It is the cartridge's responsibility to set the restart vector and/or initialize basic as needed. The code was disassembled on my own B128-80 machine.
Steve
Edit: I re-read the kernal source and got it all wrong... hopefully the description above is now correct
I just tried this program, and at least it seems to execute on startup:
org $6000
.byte #<lo, #>lo, #<lo, #>lo, #<lo, #>lo
.byte $c3,$c3,$cd,$36
lo: ldx #0
l1: lda l2,x
sta $0400,x
lda l2+256,x
sta $0500,x
inx
bpl l1
jmp $0400
l2:
rorg $0400
[ C2N232 code follows ]
That is, the code is copied to $0400 but when it is executed the machine crashes into the monitor. Hm, perhaps it has something with initializing vectors as you mention. For this matter I could skip the autostarting section and SYS it from Basic. As you see I set $6002 to $6005 with the same address all over. At least the second entry should be a vector to warm start address, but I dunno about the third one unless there really isn't 24 bit addressing as I first thought.
Oh well, now I have wasted two 2764 EPROMs. I have six more to go before I need to break out the EPROM eraser. I also know the number of erase and write cycles likely is limited on old chips, but unfortunately it doesn't seem like I can use VICE to do rough testing of this?
Ok, I just found out bank 15 corresponds to bank "romio" in VICE's monitor. I assumed it would be "ramF" but apparently that is used on some other Commodore computer.
Anyway, I just found out JMP $0400 from within the machine code makes the computer lock up. However if I transfer it to $0400 and from Basic run SYS1024, it starts up as it should. Unfortunately it seems the precompiled Windows binary for cbmlink is faulty. I will probably install MinGW and recompile it myself.
Quote from: carlsson on January 10, 2010, 09:28 AM
Ok, I just found out bank 15 corresponds to bank "romio" in VICE's monitor. I assumed it would be "ramF" but apparently that is used on some other Commodore computer.
Anyway, I just found out JMP $0400 from within the machine code makes the computer lock up. However if I transfer it to $0400 and from Basic run SYS1024, it starts up as it should. Unfortunately it seems the precompiled Windows binary for cbmlink is faulty. I will probably install MinGW and recompile it myself.
I wrote some ML programs that reside at $0400 but none of them seem to run in vice at all. I'm not sure if my settings are wrong. My copy of cbmlink works fine... it's what I used to develop my CBMXfer.
I finally got my hands on a 24K Ram cartridge for the B128. Ernie Chorny lent it to me at the TPUG meeting last night and I plan on reverse engineering it, plus documenting it for my web page. It has three 6264 RAM chips, a 74S00 NAND, some resistors, caps and two jumpers.
Anyway, this will make development a little easier.
Steve
Quote from: Diddl on January 05, 2010, 10:52 PM
I Have made an alternative firmware for the XS-1541: IEEE2IEC (http://ieee2iec.t-winkler.net/)
You can attach any IEC drive from your commodore computer. It works as a bridge and transforms all command at low level (TALK, LISTEN, UNTALK, UNLISTEN, IECIN, IEOUT). Source code for Atmel AVR644 is inluded.
I've been busy and didn't give this much thought, but now I'm interested in trying this. Does the "bridge" work in both directions, or just IEEE --> IEC ? If the latter, would it be possible to adapt so that it could be bi-directional? What I'm thinking is a small board that has IEEE female edge connector on one side for direct connection to PET/CBM without the need for a cable, and IEC female on the other end. On sides would be an SD card slot and USB. On the board would be IEEE pin connector to attach to centronix-type IEEE cable or internal IEEE like on 8296 computer.
With appropriate firmware this could be:
- SD card for PET/CBM
- SD card for C64/128/VIC etc
- Adapter to connect 1541 to PET/CBM
- Adapter to connect 4040/8050 to C64
- Connect 1541/4040 to PC via USB
Any thoughts?
Steve
I believe Nils is working on a new revision that will include some of this and more, eth and LCD. However if my understanding is correct his efforts are currently on David65. Perhaps he will chime in here.
That would be fantastic. I know a simple plug-n-play solution for the PET would be great and would help all those that can't find the old drives, or like me don't want to have to mess with big bulky boxes.
Steve
Quote from: carlsson on April 14, 2009, 02:59 AM
While I actually didn't try to plug in an IEEE drive into the computer, I believe you're correct. Since Commodore left out tape routines in the first place due to being short of ROM space, it would be a miracle if Uz' could squeeze IEC routines into the same 8K while keeping the IEEE routines in place.
That is actually not true. The kernal contains several instances of unused space filled with $AA, perhaps to pad different sections to specific addresses. There are also some routines which would rarely be used (or never at all), like the coprocessor functions.
Therefore the Uz's kernal contains both routines (IEC and IEEE). The kernal checks upon each reboot whether a serial device is connected. If so, it switches the routines to IEC. Otherwise they remain unchanged.
My goal is to change Uz's kernal so that it automatically checks every device and selects the appropriate routine. The idea is to call an IEEE routine first, then check the bit 7 in status variable which indicates that the device is not present. If it is not present on the IEEE bus, then call the IEC routine and mark the device in memory so that next time the kernal will know to call only the IEC routine.
I have been playing with the kernal source code, and came up with a first revision. The kernal does boot, but I am unable to test it further because the 6526A CIA in my Commodore 610 is broken, and I don't have any IEC devices to check. But perhaps someone could try this kernal and check whether it works, so that I would know it is a good approach.
Quote from: Michau on July 04, 2010, 03:18 AM
Quote from: carlsson on April 14, 2009, 02:59 AM
While I actually didn't try to plug in an IEEE drive into the computer, I believe you're correct. Since Commodore left out tape routines in the first place due to being short of ROM space, it would be a miracle if Uz' could squeeze IEC routines into the same 8K while keeping the IEEE routines in place.
That is actually not true. The kernal contains several instances of unused space filled with $AA, perhaps to pad different sections to specific addresses. There are also some routines which would rarely be used (or never at all), like the coprocessor functions.
Therefore the Uz's kernal contains both routines (IEC and IEEE). The kernal checks upon each reboot whether a serial device is connected. If so, it switches the routines to IEC. Otherwise they remain unchanged.
My goal is to change Uz's kernal so that it automatically checks every device and selects the appropriate routine. The idea is to call an IEEE routine first, then check the bit 7 in status variable which indicates that the device is not present. If it is not present on the IEEE bus, then call the IEC routine and mark the device in memory so that next time the kernal will know to call only the IEC routine.
I have been playing with the kernal source code, and came up with a first revision. The kernal does boot, but I am unable to test it further because the 6526A CIA in my Commodore 610 is broken, and I don't have any IEC devices to check. But perhaps someone could try this kernal and check whether it works, so that I would know it is a good approach.
I will attempt to test this, probably in a few days. My understanding is UZ had to remove the NTSC/PAL test to make everything fit and that his kernal is PAL. I'm in Canada and using NTSC... have you looked into this? If you're modifying the kernal it would be nice to reduce the startup time on 256K machines by loosening the memory test routines, perhaps by checking only the first byte of each page rather than all 256 bytes. Perhaps a check can be done at startup for some key to re-enable a full mem test. Also, perhaps a small change to the startup message so we can tell that it's a modified kernal. If there is additional room available perhaps some additional features can be added.
I just haven't had the time to work on my cartridge solution so thanks for jumping in!
Steve
I looked and Uz's kernal does check for PAL/NTSC jumper. Sorry, looked at a wrong file. Uz's kernal is PAL only indeed. Mine is PAL/NTSC as original. In fact, this is only 17 bytes for CRTC data and 3 machine instructions, so it doesn't take up much space.
Currently there are about 140 free bytes in the kernal. I will play with it more when I'm back. Right now I am told that my 8250LP arrived via courier, hopefully the CIA chips too so I will have something to test.
Quote from: Steve Gray on March 20, 2010, 11:10 PM
- Adapter to connect 4040/8050 or SFD-1001 to C64/128
Fixed that for you. :)
Quote from: airship on July 12, 2010, 06:32 AM
Quote from: Steve Gray on March 20, 2010, 11:10 PM
- Adapter to connect 4040/8050 or SFD-1001 to C64/128
Fixed that for you. :)
Thanks, but it still could use some fixing...
- Adapter to connect 2031/2040/4040/8050/SFD-1001/8250/8250LP/9060/9090 to VIC-20/C64/SX-64/Educator64/C128/C128D/C128DCR/C16/C116/+4/C65
(I couldn't remember the model numbers of the 8 inch IEEE drives ;-) )
Steve
Quote from: Steve Gray on July 13, 2010, 11:44 AM(I couldn't remember the model numbers of the 8 inch IEEE drives ;-) )
Would that be the CBM 8280?
Still in Aberdeen, Scotland,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug (http://videocam.net.au/fcug)
July 24-25 Commodore Vegas Expo 2010 - http://www.portcommodore.com/commvex (http://www.portcommodore.com/commvex)
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.
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.
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.
OK, thanks for the report. I will have my EPROM burner tomorrow so I will try it on a real 610.
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.
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.
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.
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)...
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 ;)
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.
I just fired VICE, put the moni.bin image from Uz' archive at $4000 and it works (SYS 16384 properly starts the monitor).
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.
Yes, a .bin ROM image does not have the two-byte load address.
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.
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.
Great improvement, looking forward for the results!
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.
Good start. I will try this on the weekend.
Steve
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...
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 :)
Cool, I had almost given up on autostarting CBM-II cartridges...
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.
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
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 :P and dedicate some RAM area for the remapping map. But it is definitely worth looking into.
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 (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
Quote from: Michau on 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 find the 256K ram nice, but I prefer the 128K BASIC ROM. You are of course free to use the 128K BASIC ROM with 256K RAM... this gives two full banks free to do whatever you want without worrying about BASIC overwritting your data, and the commercial software runs fine. BASIC won't use the extra banks but, realistically, how much space do you need for variables? Your BASIC program will still be limited to 64K.
I wrote an "un-assembler" that took any code and created an assembler file by loading the code into bank3. I wrote a music player for C64 Master composer files by reading the song into the unused bank and having the playback code in bankf. I wrote a file copier that simply read files into bank3 and wrote them back after swapping disks.
Steve
This is the second cartridge revision. It should support automatic device type discovery. So now it is possible to use IEEE and IEC devices at the same time!
SYS 24586 - disable IEC
SYS 24589 - enable IEC/IEEE
How does it work? When a device is first accessed (by KERNAL routines TALK and LISTEN), the cartridge tries to find it on the IEEE bus, by trying to open some file on it. If opening the file does not yield the error "Device not found", the device is thought to be present on the IEEE bus. Otherwise the device is supposed to be found on the IEC bus.
The device status is cached in memory at $F03FF. The first 4 bits contain the device number (4-15), and bit 7 indicates IEEE status (0 - device is IEEE, 1 - device is IEC).
All subsequent accesses to this device will look at this cached status variable and choose appropriate routines (IEEE or IEC). This way device status needs not to be rechecked every time.
There is also another status variable at $F03FE, which holds status of the previous device. This way, for example, you can copy files from one drive to another, and the cartridge remembers status of both devices without the need of constant rediscovery. Only when you try to access a third device, the first status is thrown away - so the cartridge always remembers the status of two last accessed devices. This speeds up operations that require using two devices at the same time.
This scheme may have an unplasent side effect - if you try to access a nonexistent IEEE device, the cartridge remembers its status as IEC. So even after you plug it in, it still will be inaccessible because the cartridge will look for it on the IEC bus according to the cached status. You can clear the statuses, for example, by trying to access two other devices (like 14 & 15) so that status variables are cleared. This is something I will need to look at in the future (for example, by attempting discovery also on the IEC bus).
I have checked the cartridge briefly with my 8250LP and 1581. It works fine - I can access both devices at the same time, without the need of any manual configuration! I can open files on both drives simultaneously, read/write from them etc. I would like to hear about your experience, and what drives you were using.
Note: variable at $F03FD is used as a temporary scratchpad for the routines. Also, I have no idea how the autodiscovery routine would work on IEEE printers, as they differ significantly from disk drives. I don't have any IEEE printer to test.
Now I am going to work on autostart routines. Plus buy an EPROM eraser, as I used my last EPROM on this one ;)
Great work! I should burn myself a cartridge and test it a little.
Would be great to know how it works with different devices. Especially the IEEE detection routine, as I've never seen before anybody doing such thing so I don't know whether I got it right :)
Looks like nobody has the courage to test this code :P
I have been debugging it extensively yesterday. I removed a bug in the IEC code causing first IEC device access to fail. Unfortunately, the autodiscovery routine does not work with my IEC 1581, so I made some other workarounds to detect drives that don't exist on both buses. This removes the need to clear the device cache after connecting a new IEEE device.
I also added some settings variable to facilitate forcing all devices to be lEEE or IEC (thus disabling autodiscovery). All printers are IEEE by default, this also can be disabled.
The autostart cartridge code is also almost ready. It does not work on P500, as I don't have one to test, and VICE does not support it. I will release the code after Christmas, when I have some free time to polish it.
Courage I have... time... not so much ;-) I have plenty of EPROMS and an eraser, so i'm willing to test when I can. Glad to hear you are making improvements!
Steve
Ok, so I burned an EPROM and did a quick test. Yes, I noticed the error on first IEC access.
It works with my MSD-SD2 as device 8 on IEEE, and the uIEC as device 10 on IEC! Nice.
It's actually funny... since my "cassette to IEC adapter cable" is plugged into the B machine and the uIEC uses the cassette connector as power I ended up using a 64C simply to power the uIEC.... I may have to add a +5V tap on the the adapter ;-)
Which, brings up a question.. what exactly do we call this "cassette to IEC adapter cable"? It needs a nifty name... Should we settle on C2N2IEC ? Or, perhaps C2IEC, CX1541 or XC1541?
(http://s3.postimage.org/ietdwp5aq/DSCN2941_800.jpg) (http://www.postimage.org/)
image uploader (http://www.postimage.org/)
Steve
I agree with Steve. I would have tested the most recent version a week ago if it wasn't for lack of time.
By the way, as you have seen from earlier pictures I hacked my uIEC/SD right away to fit a female IEC connector. Actually that connector came loose on the side with my C2N232I that I once bought from Marko/Nicolas. I brought the whole uIEC/SD/IEC adapter to Germany in August 2009 and the first thing Nicolas said was that he recognized the female IEC connector that he once sourced for the C2N232I. Apparently they were a bit difficult to find for a good price.
Hopefully I'll get around to test this one in the weekend or over the Christmas holidays.. well, one can always hope.
Quote from: Steve Gray on December 17, 2010, 03:25 AM
It works with my MSD-SD2 as device 8 on IEEE, and the uIEC as device 10 on IEC! Nice.
This is great news - it means that autodiscovery works even with non-Commodore IEEE drives! Better than I expected ;)
Quote from: Steve Gray on December 17, 2010, 03:25 AM
Which, brings up a question.. what exactly do we call this "cassette to IEC adapter cable"? It needs a nifty name... Should we settle on C2N2IEC ? Or, perhaps C2IEC, CX1541 or XC1541?
I'd opt for C2IEC for short... I don't like overly long acronyms, and the cable isn't just for 1541 :)
Quote from: carlsson on December 17, 2010, 06:13 AMBy the way, as you have seen from earlier pictures I hacked my uIEC/SD right away to fit a female IEC connector. Actually that connector came loose on the side with my C2N232I that I once bought from Marko/Nicolas. I brought the whole uIEC/SD/IEC adapter to Germany in August 2009 and the first thing Nicolas said was that he recognized the female IEC connector that he once sourced for the C2N232I. Apparently they were a bit difficult to find for a good price.
I have been looking for these connections for many hours over the Internet. Finally I found a shop which sold them. They were very cheap actually, I can try to locate it again for you if you need. I bought two for myself, so I also have one free.
Ladies and gentlemen, this is the first official release of the automagic & autostart IEC cartridge :)
The cartridge now installs IEC routines on boot, and displays an appropriate message. No setup / SYS calls necessary, just Plug&Play ;)
The variables were moved into the top of screen memory, as I have a feeling that they're less likely to be overwritten there. So there go:
$FD7FF - status of current device (bit7=0 - present on IEEE bus, bit6=0 - present on IEC bus, bit5=1 - device status was overridden, bits4-0 - device number).
$FD7FE - status of previous device
$FD7FD - temporary variable
$FD7FC - bus overriding (bit7=1 - override autodetection, then bit5=1 - all devices are IEC, bit5=0 - all devices are IEEE, bit6=1 - all printers (device4&5) are IEEE).
If both bits 7 and 6 of device status are 1, then the device was not found on any bus. The device status will then be rechecked on next access. This allows hot-plugging of devices.
There's also a bonus for Steve, a fast RAM check on power on ;)
I must say I'm slightly jealous... you have the ultimate B-series machine, which is something I've been trying to make for a while now. Congrats! Very nice job. I'm going to have to try to assemble my own BX720D ;-)
I look forward to the new IEC features you are working on. Oh, and thanks for the fast RAM check!!!
Steve
I haven't yet had the opportunity to try the latest firmware, but I'm on my way. At least I have set up my 610 as a standalone workstation:
http://www.geting.se/viewimage/image/287778-cbm610-corvus-setup.jpg (http://www.geting.se/viewimage/image/287778-cbm610-corvus-setup.jpg)
The Philips monochrome monitor has the option to toggle between green-on-black or black-on-green. The camera with its flash doesn't do the monitor justice, but I prefer black-on-green.
I suppose I might reconfigure my uIEC/SD to device #10 as the Corvus currently is #8 and the 2031 is #9. But more on that later...