The Nibbler computer

[candrews]

Sorry Craig I was just refering to afilers earlier post in this thread where he said he had the document but as you've seen its a dead link.
I've had no luck finding it elsewhere. Maybe try a PM to 'afiler' but his profile says he's not been active for 11 years.

Does anyone have any evidence that the 4K / 8K Nibbler expansion RAM board ever actually became a product?

 

[candrews]

For those interested in Digi-Key's Nibbler, build files for version 0.9 of my workalike board and NIBL ROMs are available for download on it's project page.
Scroll down to SC/MP for the Nibbler project files, Nibbler 4K/8K RAM board board (underway), as well as about a dozen other SC/MP based and SC/MP emulator projects from other people.

Documentation » Bits Of The Golden Age

SBC-85 Download SBC BUS Specifications Working Document —–>>>>> Download SBC BUS Specifications Working Document <<<<<—– SBC-85 CPU...

bitsofthegoldenage.org

 

[Bruce Tomlin]

I went ahead and added SC/MP to my assembler. Of course it's so simple that it only took a few hours, but it took a bit longer to push a new version of my assembler.

asmx multi-CPU assembler

Now that I have an assembler, I am finally able to do a full round-trip disassembly and reassembly and verify identical results.

The original listing had a few weird things:

- Numbers that started with a 0 were hexadecimal (most modern stuff uses a leading 0 to indicate octal)
- Macros were of course their own unique implementation. Almost every assembler has its own unique way to do macros.
- The same applies to pseudo-ops and allowed characters in symbols.
- My macros couldn't do variable parameter lists, but there was no real need for the macro features of the old SC/MP assembler here, it was just patching over deficiencies elsewhere.
- The big thing was 8th-bit terminated strings. When they were only one character long I had to add a null string as the first parameter because I didn't have a "number of parameters" for my own assembler's macros.
- It also had its own way of doing local label scope based on a ".LOCAL" directive. My assembler does it based on the last non-local label. Arguably that was a better way to do it, but I'm not going to change my handling of local labels right now. So they had to be demoted to "normal" labels.

Of course I found errors in my hand-made listing, and even one wrong byte in the hex that I typed in from the original scan, because it was hidden in a JS pseudo-op that only shows two of seven bytes in the listing. The corrected files are attached.

And the 18 bytes at the end were not in the listing. Apparently in the original ROM set, 0FEE-0FFF is an identical copy of 07EE-07FF. I have set them all to zero in my version of the hex file.

 

[candrews]

I went ahead and added SC/MP to my assembler. Of course it's so simple that it only took a few hours, but it took a bit longer to push a new version of my assembler.

asmx multi-CPU assembler

Now that I have an assembler, I am finally able to do a full round-trip disassembly and reassembly and verify identical results.

The original listing had a few weird things:

- Numbers that started with a 0 were hexadecimal (most modern stuff uses a leading 0 to indicate octal)
- Macros were of course their own unique implementation. Almost every assembler has its own unique way to do macros.
- The same applies to pseudo-ops and allowed characters in symbols.
- My macros couldn't do variable parameter lists, but there was no real need for the macro features of the old SC/MP assembler here, it was just patching over deficiencies elsewhere.
- The big thing was 8th-bit terminated strings. When they were only one character long I had to add a null string as the first parameter because I didn't have a "number of parameters" for my own assembler's macros.
- It also had its own way of doing local label scope based on a ".LOCAL" directive. My assembler does it based on the last non-local label. Arguably that was a better way to do it, but I'm not going to change my handling of local labels right now. So they had to be demoted to "normal" labels.

Of course I found errors in my hand-made listing, and even one wrong byte in the hex that I typed in from the original scan, because it was hidden in a JS pseudo-op that only shows two of seven bytes in the listing. The corrected files are attached.

And the 18 bytes at the end were not in the listing. Apparently in the original ROM set, 0FEE-0FFF is an identical copy of 07EE-07FF. I have set them all to zero in my version of the hex file.

Thanks for the source file listing !