Anyone heard of the "Nibbler" by Digi-Key around 1978?

[Phil__G]

Thanks Ian, much appreciated

If theres any remaining doubt, I saved my KB+ source at every dev stage, before & after every command or feature was added... a full audit trail

[nlpe1goo]

Originally Posted by Phil__G

Thanks Ian, much appreciated

If theres any remaining doubt, I saved my KB+ source at every dev stage, before & after every command or feature was added... a full audit trail

Hi Phil
Did you remove the bug in hexdump I found in kitbug in your own version(s)? The bug isn't that bad but won't display a dot when a character has the value 0x7F.

[SiriusHardware]

For those who don't already know, Craig has posted another interesting instalment:-

https://www.youtube.com/watch?v=ezwSMqDYGp0

[Phil__G]

Originally Posted by nlpe1goo

Hi Phil
Did you remove the bug in hexdump I found in kitbug in your own version(s)? The bug isn't that bad but won't display a dot when a character has the value 0x7F.

No, but its on the to-do list Nick As bugs go, its harmless
Not sure what 'my own versions' means? KB+ isnt a version of anything

[SiriusHardware]

For the benefit of recent arrivers and people like me with bad memories, could you give a brief summary of what KB+ is since there seems to be a degree of confusion about it?

[Phil__G]

That would be a long post likely to need longer than the forum's edit window G
I'm as baffled as yourself as to why there is confusion
The shortform story:
As you know in 1980 I built the Aitken SC/MP and added more ram and NS Kitbug in eprom. Kitbug has only three commands, two operate at the byte level - modify and type. It also has a 'Go' command which doesnt have an argument and so needs convoluted register settings before entering 'G'.
This was very limiting and I began adding to and changing Kitbug, with a formatted memory dump, inline print, serial loader and more, all integrated into what I then called KitbugPlus, since by then it had moved on from its Kitbug roots and I'd several 2716's some plain Kitbug and some with additions and so used KB and KB+ on the labels to identify them. These same routines are still in the current version with little change from 1980. Later changes included an SPO256 driver (since dropped), baudot serial for RTTY, etc. When I restarted what was now 'retro computing' as a hobby I picked up KitbugPlus from where I'd left off, and adapted it to Karens PICL (which has some I/O & memory-map peculiarities). Mike used it for his 18877. Then I was asked by Kris to port it to the MGH board. Having a full & flexible memory map this meant I could further expand KitbugPlus and thats the version we have today but I want to emphasize this wasnt/isnt some triumph of software engineering, its just the result of a sub-average enthusiast tinkering in his shed over the decades.
So KitbugPlus is my monitor for SC/MP hardware systems & emulators, currently with the following command set:
Copy<U/D>
CS
Display xxxx
Go xxxx
List xxxx
Modify xxxx
Offset xxxx yyyy
Regs
Sload xxxx
Type xxxx
Nibl

C is an 'intelligent' copy in that it can handle overlapping blocks of memory, but can also 'fill'. CS is clear screen, D is the usual tabulated memory display in hex/ascii, G runs a program from address xxxx, L lists in 'instruction-length-aware' format, M is modify, O calculates the relative jump offset to jump from address x to y, R displays the registers, S is the fast serial loader (2400 no delays), T is a byte by byte memory dump. It has inline print and you can preset register contents before 'G xxxx' if required. N command for NIBL isnt there if its not applicable.

It normally lives in page zero so it runs from reset, and includes an option for a boot menu ( KB+ / NIBLE / NIBLFP ) but on the PICL its a limited subset run from 7C00 in NVram. There are similar reduced versions for the micro-introkit etc. The full one is 1700 decimal bytes, and the same 'full' image runs on the MGH8060, MGH8060GAL and SCMPII-Max without changes and on Ron Dekker's board with a memory-map change. Theres a full document within the MGH8060GAL zip on philg.uk but thats it in an oversized nutshell
Cheers
Phil

[Phil__G]

Originally Posted by Phil__G

Theres a full document within the MGH8060GAL zip on philg.uk but thats it in an oversized nutshell
Cheers
Phil

Whoops I checked and for some reason the KB+ overview wasnt in the MGH8060GAL zip, I've added it now. The file is called "kitbugplus_scmp.pdf"
within
https://mccrash-racing.co.uk/philg/scmp/mgh8060gal_source.zip
and it was last updated Nov '23
Cheers
Phil

[HelloWorld]

Originally Posted by Phil__G

You were right Craig, I did - some of it back in 1980 and some more recently, the PICLv2 has a subset of the full KB+ and the MGH8060GAL has the full current version.

Apologies if my confusion was confusing. I previously thought you wrote it to only run on PICL platform, I.e., it was reliant and integrated into the emulator. Then I realized it was separate from the emulator and will run on any platform, my confusion was on the platform, not the source

[Phil__G]

Part of the confusion was my fault, sorry everyone, but I think we're all deconfused now

[SiriusHardware]

Epic post, Phil. I was expecting something along the lines of

"Kitbug+ was an enhanced alternative to Kitbug which I wrote some time ago."

I think it is fair to say we have the definitive answer now, thanks for taking the time to set that out.

Incidentally, if composing a long message which is likely to contain a high number of missed errors I sometimes compose it in Notepad and then cut and paste it into the forum's editor afterwards. It's just a shame I don't follow my own advice more often, hence the frequent last minute edits to my posts.

[Phil__G]

I do like NIBL, it has some peculiarities but you soon get used to them.
For example if you want a new line, in conventional BASIC you'd just say PRINT whereas in NIBL you have to use PRINT""
When PRINTing a mix of text and variables, each part needs it own separate PRINT though you can suppress newlines for continuity.
If you want an INPUT to have a text prompt, that needs to be done with a PRINT. Internally its uppercase-only, though you can print lower case.
Conventionally the abbreviation for PRINT is ? but in NIBL its PR. The @ for directly reading & writing memory is like conventional PEEK & POKE, and any numbers or variables over 32768 will go negative! (n-65536)

https://www.mccrash-racing.co.uk/philg/scmp/SCMPDLY.NIB

Given the resources the string handling is very flexible (in that you have to do it all yourself!) and mixing in some M/C is easy with TOP & LINK
NIBL is delightfully different, its really cute!

[nlpe1goo]

Originally Posted by Phil__G

NIBL is delightfully different, its really cute!

Yes, I like the SC/MP assembly code. After 45 years I still do remember the full instruction set of it. Yes it was my first computer ever.
But I agree NIBL is also cute it is simple but you can do a lot with it.

[Phil__G]

I use a form of hex that I call PEX which is much faster for NIBL to handle as theres no 'add 7 if above 9' hex conversion which really slows NIBL down.
The PEX lines live in REM statements at the start of the NIBL program and can be seen in BASYS and the disassembler in the KO2019 package.
PEX looks like this:

1 REM @HLBCACELBC@CALD@HLJNJ@FMDB@ILOKLDDCHO@@@FMDB@IL
2 REM OBLDHNHO@@@FMDB@IL@BIH@BLD@AAO@AAM@AKJNJILNKD@LM
3 REM @ALDKMHO@@@FMDB@ILLM@FMDB@IHOKCO@HLDKICCLD@OCGLB
4 REM BNALALALAL@BODOFID@DODCJI@@BODD@COLBBNMD@O@BODOF
5 REM ID@DODCJI@@BODD@COLD@ICGLDFOCCCO@@@@@@@@@@@@@@@@

To load this into ram, first variable M is set to the memory destination address, P is set to the current page number,
and S to where the actual PEX characters begin. On page one its later because thats where NIBL variables etc are stored.

M=#7F80:S=#000A
P=@#1012:@#1041=P*16:IF P=1 S=#1128

Then we read through a PEX line, L is the current line (of 5 lines) , B is a pointer along the line and A points to the current PEX pair:

FOR L=0 TO 4:FOR B=0 TO 46 STEP 2:A=S+B+L*57

then two PEX characters are converted to a byte:

X=(@A) AND 15:Y=(@(A+1)) AND 15:Z=(16*X)+Y

...its poked into memory, the ram pointer is bumped and we go for the next character pair, then the next line, skipping the line numbers and 'REM 's:

@M=Z:M=M+1:NEXT B:NEXT L

Yes its slow, but not as slow as NIBL loading intel hex so I've found it really worthwhile.
In the KO2019 package, any hex output from BASYS or from the Disassembler was very slow using NIBL directly, so thats where M/C comes in,
and theres also a serial fastloader in the example above (identical code is used in basys & the disassembler).
Loading progs into the NVram projects only needs to be done once anyway, for example in the PICLv2 package theres a PEX loader to
install a subset of KitbugPlus, again it only needs to be run once when using NVram so its 'fast enough'

I've a few utils for creating PEX from binaries and from Intel hex, all easy peasy as basically its just text
Theres not much you can't achieve with NIBL & a bit of SC/MP m/c

[HelloWorld]

I wrote some ramless diagnostic code for my SC/MP Nibbler project and I am wondering how universal it is, but the Nibbler is the only SC/MP board that I have. Baud rate is 2400 for 4MHz scamp II. It only requires the TxD be on flag 0 (inverted) or flag 1 (not inverted), the RxD be on Sense B, and the ROM located at 0x0000. If someone has a MK14 or other SC/MP platform on their bench and time to burn an eprom and try it out, I would be interested if everything (or anything) works. To get to the command prompt, Sense A and SIN need to be at 0V at reset, or else it will enter low level infinite loops.

.asm , .lst, .hex, and users guide are at the link below.

Now I am off to port Phil’s resident monitor over to the Nibbler.


Thanks
-Craig

https://bitsofthegoldenage.org/download/sc-mp-ramless-diagnostic-utility/

[Phil__G]

Here ya go:

https://youtu.be/C5trHgr8qKU

Dont know what I'm doing as I havnet read the doc yet, will do that later
One thing I noticed, the 'map ram' scan started at 0F00, where my RAM starts at 0800 immediately after KB+ yet a manual ram test from 0800 seems ok
Most likely me, what we used to call in Post Office Telephones, "Subs Misop"

I'm most impressed with your ramless serial Craig!
Cheers - Phil

EDIT: forgot to say I took the on-reset SIN and SENSE tests out to make it go straight into the menu

.

[Phil__G]

Originally Posted by Phil__G

One thing I noticed, the 'map ram' scan started at 0F00, where my RAM starts at 0800 immediately after KB+ yet a manual ram test from 0800 seems ok

Line 862 (in my notepad) sets the start for the ram map to 0x0F00:

        LDI     0FH             ;SET P2 TO STARTING POINT
        XPAH    P2
        LDI     00H
        XPAL    P2
MAP_TEST:

Originally Posted by Phil__G

my RAM starts at 0800 immediately after KB+

what I mean is, immediately after where KB+ would normally be. In this case theres just the diagnostic from 0000 to 07FF, the rest of the memory map is full of 0xFF

0000 to 07FF is rom (normally KB+)
0800 to 0FFF is ram normally for KB+ scratchpad, stacks, vars etc)
1000 to 1FFF is ROM (normally NIBL-E)
2000 to 2FFF is ram (NIBL-E page 2 etc)
3000 to 3FFF is rom (normally page3.sys)
4000 to 7FFF is ram (the bulk of r/w memory)
8000 to FFFF is rom (NIBL-E toolkit, NIBL-FP etc)

[Phil__G]

Just a suggestion Craig, the Map ram command tests every single byte to see if it can be written, but since its unlikely that address decoding is more granular than 256 bytes, you could just increment the pointer MSB through memory and leave the LSB alone (doesnt matter what it holds) which would print out the memory map much more quickly (presently takes 25 minutes or so). The 'T' command gives your full memory test so I just wondered if 'M' needs to be so granular? Just a thought...

[Paul_G3WYW]

Been following these SC/MP threads with interest, the TeleKit was very informative.
The Scrumpi book was interesting as I have built a similar version using TIL311 Hex Displays for the ADDR and DATA lines.
Ive also built on breadboard a HEX keypad using a PIC16F628 that replaces the 8 databit switches, making it easier (and faster) to enter code . I'll write it up and post here if there is interest.

Following links to the 'Nibbler' on YouTube took me to this link
https://bitsofthegoldenage.org/download/sc-mp-ramless-diagnostic-utility/
where 'Hello World' has developed and published a RAMless diagnostic for SC/MP that only needs a Serial port connected to SB and F0 as normal and runs on a PuTTY at 1200 baud.

[Phil__G]

I know you love saving a few bytes Craig and diags is exactly a full 2k - here's nine redundant LDE's in the command loop:

        LDI     /PUTS-1         ;P3 IS PUT STRING
        XPAH    P3
        LDI     #PUTS-1
        XPAL    P3

        LDE
        XRI     '?'             ;IS IT ?
        JZ      CMD_ENTER       ;YES, DISPLAY COMMANDS

        XRI     'V'!'?'         ;IS IT A V?
        JZ      CMD_V           ;VERSION
        
        XRI     'A'!'V'         ;IS IT AN A?
        JZ     CMD_A            ;ADDRESS DECODER TEST
        XRI     'F'!'A'         ;IS IT AN F?
        JZ      CMD_F           ;FLAG SEQUENCE
        XRI     'M'!'F'         ;IS IT AN M?
        JZ      CMD_M           ;MAP MEMORY
        XRI     'I'!'M'         ;IS IT AN I?
        JZ      CMD_I           ;INSTRUCTION FETCH TEST        
        XRI     'R'!'I'         ;IS IT AN R?
        JZ      CMD_R           ;READ INPUTS TEST
        XRI     'S'!'R'         ;IS IT AN S?
        JZ      CMD_S           ;STICKY BIT TEST
        XRI     'T'!'S'         ;IS IT AN T?
        JZ      CMD_T           ;TEST RAM
        XRI     'W'!'T'         ;IS IT AN W?
        JZ      CMD_W           ;WRITE/READ RAM

        LDI     /CMD_MSG2       ;MESSAGE IN P2
        XPAH    P2
        LDI     #CMD_MSG2
        XPAL    P2
        XPPC    P3
        JMP     CMD_PROMPT      ; NO, TRY AGAIN

Originally Posted by Paul_G3WYW

...where 'Hello World' has developed and published a RAMless diagnostic for SC/MP that only needs a Serial port connected to SB and F0 as normal and runs on a PuTTY at 1200 baud.

thats what we're discussing now Paul.
Your keypad sounds similar to my Cosmac Elf one! Yes please post it, the more the merrier!

[HelloWorld]

Originally Posted by Phil__G

One thing I noticed, the 'map ram' scan started at 0F00, where my RAM starts at 0800 immediately after KB+ yet a manual ram test from 0800 seems ok


.

Thanks for taking the time to look at this Phil. Yes, I accidentally left the start of the ram test near to]he top of the ROM. I put it there to speed up the test but forgot to change it to zero
I will address that. I need to upload a new version because I added a halt test.