• Please review our updated Terms and Rules here

NABU PC Emulation under MAME

I was playing with NABU Basic in mame, and came across a couple of unusual behaviors and was curious if they happened on real hardware.

For example, RND(0) and RND(1) behave exactly opposite of the way I would expect. RND(0) should repeat the last value and positive values like RND(1) will give the next value.

10 FOR R = 0 TO 1 : FOR I = 1 TO 8 : PRINT R,RND(R) : NEXT : NEXT


Also LOCATE is CURSOR in Nabu Basic, but the parsing of a line doesn't work correctly. Any cursor command should be left on its own at the end of a line.

100 FOR L = 23 TO 1 STEP -1 : CURSOR L,L
110 PRINT L : NEXT

will work, however

100 FOR L = 23 TO 1 STEP -1 : CURSOR L,L : PRINT L : NEXT

will give a syntax error.


Could someone with real hardware check the behavior of RND and CURSOR to see if it matches the emulator?
 
Nabu Basic seems kind-of braindamaged, looking at it. Like, it's trying to be Microsoft Basic, but it very much isn't.
 
usotsuki said:
Nabu Basic seems kind-of braindamaged, looking at it. Like, it's trying to be Microsoft Basic, but it very much isn't.
Click to expand...
Yeah it's kind of an interesting dialect.

For instance, you can type "R U N" and it will interpret that just fine as "RUN".

CLS == ERASE in Nabu Basic.

Strings are handled in an interesting way, with MID$ being replaced by using the variable name directly, and the indexes provided giving the range of characters.

A$ = "12345"
PRINT A$(3,4) will print "34"
 
Finally got around to finishing up working support for double sided disks, both 5.25 and 3.5 variants. My repo should now have the latest commits for this feature in it.

The DPB tables were provided by @snuci, however i discovered that there is another byte proceeding the 16 byte DPB in the out of band MFM data that tells CPM to treat disks as doubled-sided and also as a non 48-TPI disk as well.

The following values seem to be used for this byte:
Code: 
00 - single sided (48 TPI)
01 - double sided (48 TPI)
02 - double-sided (NOT 48 TPI)
If you are using a 3.5 inch disk image you will need an extra CLI option to set one of your drives to the 3.5 format (the default is 5.25) -option<n>:fdc:fdc:<d> 35dd where <n> is the slot number of your fdc controller and <d> is the drive number (0 or 1)

This also removes support for the osborne disk images. I did this because i don't think they were really used much, being the default if the MFM out of band data is missing, and it was causing issues when determining the disk type. Specifically it causes issues when trying to use a data disk without a bootloader installed on it would always show up as a osborne disk, instead of the appropriate nabu disk type.
 
Wormetti said:
RIP osborn. I guess I can always keep the old version if I really want to play with NABU BASIC. Good to see you updating MAME again!

https://gtamp.com/nabu/nabu-mame-exe-only.zip Windows build, this should be the double sided update, I didn't even test it. It's just the exe for now. Previous version with all of the files is still on my site.
Click to expand...
Well I don't think you need osborne disks for basic, it should save and load to nabu disks just fine.
 
Any way to get nabupc to work with "naburn8mb" diskdef files?
Wouldn't be floppy emulation, but maybe another had.

Just wondering.
 
brijohn said:
The DPB tables were provided by @snuci, however i discovered that there is another byte proceeding the 16 byte DPB in the out of band MFM data that tells CPM to treat disks as doubled-sided and also as a non 48-TPI disk as well.

The following values seem to be used for this byte:
Code: 
00 - single sided (48 TPI)
01 - double sided (48 TPI)
02 - double-sided (NOT 48 TPI)
Click to expand...

After a bit of head scratching while disassembling the cpmldr, I eventually determined that I had landed on the code that checks if a disk is a NABU disk by attempting to configure the DPB from the out of band data if present. While the loader skips 4 of the 5 bytes between the gap bytes ($4E) and the DPB data, it does indeed save the byte just prior to the DPB (17 bytes by the way). It was easy to see the correct density getting saved in the drive configuration based on it's value, but I wasn't sure what it meant if the byte value was > $01. The density value that is set in the drive config (if not 40 or 80) is 160 ($A0) by the way (quad?). Curious, did you or @snuci see a drive image from Leo with that byte set to $02 (or something else)?

The only thing to add is that bit 2 of that particular byte (or drive byte as I've been referring to it) is used to determine if sector translation is needed or not, and the xlt value in disk parameter header is set accordingly.
 
Last edited:
Golden Child said:
For example, RND(0) and RND(1) behave exactly opposite of the way I would expect. RND(0) should repeat the last value and positive values like RND(1) will give the next value.
Click to expand...
Based on what BASIC dialect? I don't know any BASIC dialect that works exactly that way. GW-BASIC e.g. knows "0" to repeat the last number, but is not limited to 0 and 1. CBM BASIC (also MS BASIC at its core) knows 0 for timer-based random numbers as well as negative and positive numbers to define the seed. So the NABU BASIC probably does its own thing, too.
 
labomb said:
After a bit of head scratching while disassembling the cpmldr, I eventually determined that I had landed on the code that checks if a disk is a NABU disk by attempting to configure the DPB from the out of band data if present. While the loader skips 4 of the 5 bytes between the gap bytes ($4E) and the DPB data, it does indeed save the byte just prior to the DPB (17 bytes by the way). It was easy to see the correct density getting saved in the drive configuration based on it's value, but I wasn't sure what it meant if the byte value was > $01. The density value that is set in the drive config (if not 40 or 80) is 160 ($A0) by the way (quad?). Curious, did you or @snuci see a drive image from Leo with that byte set to $02 (or something else)?

The only thing to add is that bit 2 of that particular byte (or drive byte as I've been referring to it) is used to determine if sector translation is needed or not, and the xlt value in disk parameter header is set accordingly.
Click to expand...
So the 40, 80, or 160 values are the number of tracks a disk has, 40 for a single sided 5.25 inch disk, 80 for the double sided 5.25 inch disk, and the 3.5 inch disks are 160.

You can view what that byte gets set to by turning on some logging options for floppy emulation in mame and viewing what gets written to track 0 when formatting a disk. Doing this I was able to verify that when formatting a single sided disk it was writing a 0, if i told it to use a 48 TPI drive, but do double sided it wrote a 1 and if i told it to use a non 48 TPI drive you got a 2 written during formatting.

Interesting, does that mean setting it to a 1 disables the XLT then? Since all the current values have bit 2 as 0 but definitely use an XLT table. I wonder how bit 2 gets set though, format never seems to write a value with but 2 being set that i have seen.
 
jefferystone said:
Any way to get nabupc to work with "naburn8mb" diskdef files?
Wouldn't be floppy emulation, but maybe another had.

Just wondering.
Click to expand...
So you probably could get it to read them if you edited the cpm3.sys file to use the proper DPB for those files instead of the one it currently used for hard drives. Though then it would not be able to read the normal HDD images.
 
brijohn said:
Interesting, does that mean setting it to a 1 disables the XLT then?
Click to expand...

Correct... it checks if the bit is set, and if so it zeros out the xlt table entry in the DPH, otherwise it sets the xlt table address. I've not seen any drive defs that didn't use translation yet, but it might come in handy.
 
Mame 0.252 has been released with the Nabupc driver now in mainline: (I don't think it has all the features of brijohn's wip though)

I thought I'd fire up the 0.252 nabupc with the nabu.ca internet adapter and use this command line but it didn't work until I went into UI/Machine Configuration and set the null_modem to 111900 baud.

./mame nabupc -kbd nabu_hle -hcca null_modem -bitb socket.127.0.0.1:5816



Just thought I'd mention it for those who want to try the nabupc.

Thanks Brijohn for the awesome mame nabu driver!
 
brijohn said:
So you probably could get it to read them if you edited the cpm3.sys file to use the proper DPB for those files instead of the one it currently used for hard drives. Though then it would not be able to read the normal HDD images.
Click to expand...
Would MAME still require that we use .chd format?
 
Sorry to flood the forum - i deleted my previous post because the binary was not complete. I did not realize the DPH of cpm 3 was different than 2.2. This new version is corrected and tested with nabu cpm 3. Source code included
 

Attachments

  • DPBVIEW.zip
    11.5 KB · Views: 9
DJ Sures said:
Sorry to flood the forum - i deleted my previous post because the binary was not complete. I did not realize the DPH of cpm 3 was different than 2.2. This new version is corrected and tested with nabu cpm 3. Source code included
Click to expand...
Oh useful. Though in addition to the DPH being different on a version 3, there are also two extra fields in the DPB that value the offset field these are called PSH (shift), and PHM (mask) and tell CP/M what physical sector size the disk uses. CP/M 3 has builtin support for sector sizes larger then 128 bytes.

Code: 
  size   psh   phm
--------|-----|-----
  128   |  0  |  0
  256   |  1  |  1
  512   |  2  |  3
1,024   |  3  |  7
2,048   |  4  | 15
4,096   |  5  | 31
 
jefferystone said:
Would MAME still require that we use .chd format?
Click to expand...
Just a bump on this question - I don't mind trying to get a 'naburn8mb' type drive to boot by editing cpm3.sys, but if it requires being in .chd format then I'll drop the thought.
 
jefferystone said:
Just a bump on this question - I don't mind trying to get a 'naburn8mb' type drive to boot by editing cpm3.sys, but if it requires being in .chd format then I'll drop the thought.
Click to expand...
Mame can load raw images as an hdd image, but in that case it will guess at the physical disk geometry (CHS). If this is different then the geomerty of the image, data won't be found in the correct place in the image. I'm not sure what the physical geometry of the naburn8mb images are but its likely you would want to convert them to chd so you can specify the correct CHS values rather then just letting mame guess.
 
You must log in or register to reply here.
Back
Top