VIC-1211A and VIC-1211M -- What's the difference?

[ka20]

The Super Expander sold in most of the world was the model VIC-1211A, but in Japan Commodore sold the VIC-1211M. I have both cartridges, but I can't determine what the difference is between the "A" and "M" models. Does anyone here know?

[Mike]

The "M" version appears to have a slightly different set of new commands and functions. Also, a command ("PIANO" (?)) to use the keyboard as piano was included, which was removed with the "A" version.

See also here: VIC-1211 Super Expander WITHOUT 3K.

AFAIK there's no ROM dump of the "M" version out in the wild. If you're so inclined, would you care to provide a ROM dump of the "M" Super Expander? This program:

Code: Select all

1 SYS57809"VIC-1211M.PRG",8:POKE193,0:POKE194,160
2 POKE780,193:POKE781,0:POKE782,176:SYS65496

produces a *.prg file of the memory range $A000..$AFFF on disk, which you then could upload here.

TIA,

Michael

P.S. moved this thread to "Collecting and History", as "General Topics" doesn't allow for attachments.

[ka20]

Michael,

Thank you for the information. I followed your instructions and I have attached the file the was produced. I've also attached a photo of the page in the manual that describes the PIANO command. I don't know Japanese, but you can see on the following page what each key is supposed to do in piano mode.

-Kelsey

[Mike]

Hi, Kelsey!

PEOPLE!

Forgive me my lack of restraint, but what has been dumped here is not just a pre-cursor to the Super Expander as we know it. It's a *completely* *different* BASIC extension, which just goes by the same name!

About the only thing it has in common with the US/EU version of SE is the support for graphics and sound, but some commands are totally different. Furthermore it allocates the graphics memory right from the start (therefore, just 29xx BYTES FREE on startup); from a quick look, there's however a command named RELEASE which possibly(!) - barring a more detailed analysis of the code - releases that memory, so the cartridge can operate as 'standard' +3K RAM expansion.

Also, judging from the manual, this version doesn't feature the gimmicky rescaling of the co-ordinate system (with X/Y=0..1023), it uses the direct pixel co-ordinates X/Y=0..159 as would anyone want.

The best thing comes at the end:

"BY S.IWATA & A.KIDA"

(and possibly also "& J.S" whoever this is ...)

Yes, Satoru Iwata from HAL Laboratory and later CEO of Nintendo!!!

<goes off to mark this day in the calendar>

Cheers,

Michael

[ka20]

If you would find it helpful, I could scan of the entire manual and attach it here.

It may be a few days before I can find the time to get to that.

[Mike]

If you would find it helpful, I could scan of the entire manual and attach it here.

Yes, that would be very helpful indeed.

I'm just combing through the code, and I've found something *very* interesting: This version of Super Expander is capable of autostarting other CBM toolkit cartridges! I suppose there's some reference to/confirmation of this in the manual.

For example, if the Programmers' Aid cartridge is also present, you get both their init messages like this:



Now how cool is this?

Edit: O.K. this sheds quite some light on the rather mysterious "70CBM" signature I encountered once when relocating the Programmers' Aid cartridge to $B000. Turns out the Japanese Super Extender specifically checks for a 70CBM signature at $7000 and a "B0CBM" signature at $B000, the latter which was present in some versions of the VIC-1112 IEEE 488 cartridge. PA in turn checks for the B0CBM signature as well.

Not only does this autostart all three cartridges on power-on/reset with all their banners, their NMI vectors are also supposedly chained and thus the (changed) KERNAL vectors are kept alive even when STOP/RESTORE is pressed!

I simply cannot be indifferent about this: CBM had established a protocol to combine (at least) these three cartridges provided the Super Expander is present. Wow.

However, the later Super Expander removed that protocol, furthermore later versions of the IEEE cartridge had their B0CBM signature also being removed. My speculation about this: when I tried the 3-cartridge combination in VICE, I got a CPU jam upon pressing RESTORE. Possibly that "cartridge chain protocol" didn't work anymore with the later versions of the KERNAL? Will investigate further.

[Kakemoms]

Wow! Thats supercool. Its like finding out that a superhero modified a Saturn rocket to reach Jupiter in 1969.. but they dropped it for a lesser version because everyone wanted to go to the Moon.

Makes me think of Dave Needle for some reason.

[tokra]

The book "VIC 20 - A Visual History" describes the differences between the cartridges on page 124. Mike, I know you have that book, too

[Mike]

Mike, I know you have that book, too

Yes ... <fx=grabs the book> ... and it confirms that the RELEASE command indeed releases (duh!) the graphics memory for other BASIC use. The other commands of VIC-1211M are also listed.

The book though doesn't mention the cartridge chaining protocol for Programmers' Aid and the IEEE-488 cartridge ...

[orion70]

This is interesting also for the ignorant amateur (me ). From an historical point of view, what's the reason why Commodore dropped such a great achievement, just to settle for... the moon?

[Mike]

Sorry, technical post:

This is interesting also for the ignorant amateur (me ). From an historical point of view, what's the reason why Commodore dropped such a great achievement, just to settle for... the moon?

As I wrote:

However, the later Super Expander removed that protocol, furthermore later versions of the IEEE cartridge had their B0CBM signature also being removed. My speculation about this: when I tried the 3-cartridge combination in VICE, I got a CPU jam upon pressing RESTORE. [...]

I did some more investigation in that direction: especially the cartridge NMI "vector" of the only IEEE ROM code that I could find (part numbers 325329-03 and 325329-04) is misbehaving: it also checks for a cartridge at $A000, which is of course there - the Super Expander. Now the NMI handlers of these 3 cartridges call each other in an endless loop, with the NMI handler of the IEEE cartridge pushing the CPU registers on each call, leading to a stack overflow and the aforementioned crash.

Note pushing the registers at this place is definitely wrong: the KERNAL NMI handler has already pushed the registers before calling a cartridge NMI handler with its JMP ($A002).

I could get somewhat reasonable behaviour by NOPing out the offending JMP ($A002) in the IEEE code, but then the keyboard handler vector at $028F still kept being reset by yet another JSR $E518 in the IEEE NMI routine. The altered keyboard vector is necessary for the function key definitions of PA to work. NOPing out *that* JSR in turn led to some other unwanted behaviour: pressing STOP/RESTORE did not anymore clear the screen. Most probably - in Programmers' Aid(!) - the call to $E518 did not anymore take place, which would have to be scheduled before setting $028F/$0290 to their intended values ($E518 resets them to KERNAL defaults) ... tangled threads everywhere.

Now from the historical point of view:

Maybe there exist earlier versions of Programmers' Aid and - especially(!) - the IEEE cartridge, which got that right. Just (probably) the information to take care of that cartridge combo didn't make it across the Pacific and so CBM USA ended up with this non-functioning arrangement. Instead of fixing this, CBM apparently decided to go the easier route and pull the teeth on Super Expander itself.

[srowe]

Note pushing the registers at this place is definitely wrong: the KERNAL NMI handler has already pushed the registers before calling a cartridge NMI handler with its JMP ($A002).
(

The NMI routine of the VIC-1112 ROM isn't called from the KERNAL NMI routine, it replaces it. I've done a complete disassembly,

https://eden.mose.org.uk/gitweb/?p=rom- ... sm;hb=HEAD

I'm not surprised that you've found problems with the chaining between ROMs with this one though. It has sections of dead code and just generally has the air that it was written by someone who wasn't too sure what they were doing.

[Edit]

I see what you mean, the autostart header points to the same address as the NMI vector. That's just plain wrong.

[Mike]

I see what you mean, the autostart header points to the same address as the NMI vector. That's just plain wrong.

Exactly.

Thank you for the hint regarding $0318 - indeed IEEE has taken over this and thus calls Super Expander from its own NMI routine. That gave me the idea to 1. re-instate the B0CBM signature and 2. simply re-vector ($B002) to $B097.

Now what happens is this:

- User presses the STOP/RESTORE combo,
- The IEEE NMI routine gets called over ($0318),
- checks for A0CBM and calls the Super Expander NMI routine,
- Super Expander checks for PA's 70CBM signature, finds it, calls PA's NMI handler,
- PA does its stuff, checks for IEEE B0CBM signature, finds it, and then:
- (with the patched value at $B002/$B003) re-enters IEEE's NMI handler right behind its JMP ($A002) call!
- and user gets a BASIC warm start with the READY prompt.

What still gets (temporarily) de-activated is the keyboard vector of PA, but I found that one is easily re-instated by issuing a KEY command.

If PA isn't present, but IEEE is, then SE also checks for the B0CBM signature, and jumps straight back to the remainder of IEEE's NMI routine.

If PA is there, but IEEE isn't, then the PA NMI routine is called via the KERNAL and SE NMI handler, doesn't find the B0CBM signature, but does the correct handling of the BASIC warmstart (JSR $E518 and then writing the new values to $028F/$0290) and then reenters BASIC with JMP ($C002).

Phew.

[Mike]

I've found the missing piece of the puzzle!

If one patches JMP ($B002) at $7070 in PA to do a JMP $B0AE instead, *everything* works!

With both PA and IEEE, this jumps right behind the vector restoring JSRs of IEEE, executing only those relevant to the IEEE vectors, and keeps the keyboard vector in $028F/$0290 alive. Before that, PA had already done all necessary housekeeping in its own NMI routine.

Without PA, the NMI entry of IEEE still needs to point to $B097, so IEEE can perform the vector inits all by itself.





Cheers,

Michael

[Mike]

Activating the IEEE hardware in VICE 3.1 does work though - sort of.

I've booted up the "Super-VIC" and then activated TDE with a SFD-1001. The drive seems to respond to commands, and I can read out the error channel, but for the moment I'm stuck getting a mounted *.d82 disk image to work ...


Edit: here's another attempt with the IEEE ROM expanded to 4K and all four ROMs attached as cartridges; with VIC-1112 hardware enabled and a SFD-1001 as drive #8 in the drive settings and then a proper hardware reset:



Attached *.d82 files still don't work though.

Edit 2: attaching a known(?) good(?) *.d82 (the SFD-1001 Test/Demo Disk as found on zimmers) and trying to load the directory with LOAD"$",8 only results in a broken listing of 0 " (the quotes are shown in reverse) - a quick peek in memory reveals only the header line with lots of zeroed bytes for the disk name/ID/DOS ID, and a defunct BLOCKS FREE line are in memory. Of course the BASIC re-linker chokes upon all those 0's and truncates the directory.

Edit 3: just attaching the VIC-1112 in VICE 3.1 with a SFD-1001 also doesn't work.

Edit 4: What *does* work is attaching a 8250 instead! YAAAY!



Here are the same ROMs re-packaged,VICMON with PA combined in BLK3 and Super Expander with IEEE combined in BLK5.

In VICE, proceed as follows:

- Settings > Virtual device traps => tick OFF,
- Settings > Drive setting > True drive emulation => tick ON,
- Settings > VIC-20 settings ... => Memory 16K (blocks 1/2),
- Settings > Cartridge/IO settings ... > VIC-1112 IEEE-488 module => tick ON,
- Settings > Drive settings > Drive settings, Drive type: 8250
- File > Attach cartridge image ... > Generic image ... => select 'blk3-vicmon-pa' > Open
- File > Attach cartridge image ... > Add to generic cartridge > Smart-attach image ... => select 'blk5-se-ieee-488' > Open

... and there you go.

The *.zip file (download) also contains an empty *.d82 disk image for you to try out.