• Please review our updated Terms and Rules here

Ampro Little Board Plus emulation in MAME - Materials available on request

KattPhloxworthy

New Member
Joined
Jan 24, 2022
Messages
6
Location
Sacramento County
Hi, all!

In case anyone is interested, I managed to finagle getting the Ampro Little Board emulation in MAME to work pretty nicely to the point where I can boot up a full system on a virtual hard disk. It took a bit of thinking because, as it turns out, many of the disk formats involved tend to be much like VMware/VirtualBox grow-as-you-use-it-type files, and CP/M tends to want lots of E5s in strategic places (especially so in hard disk images in the partitions' directory areas) to indicate that the disk has not been used yet. That and, to a lesser degree, the love of compression abounds.

If anyone would like me to share any of my materials, please let me know!
 
I'd love to see your work get integrated into mainline MAME. Have you considered issueing a pull request on GitHub?
 
I'd love to see your work get integrated into mainline MAME. Have you considered issueing a pull request on GitHub?

I had only done a pull on GitHub to make 96tpi 5 1/4" diskette images a possibility on all four drives, which has since been integrated. I'm talking about like disk images and the like. It is a bit squirrely with IMD files and newly-created hard disk files. I was running into problems of putting files on newly-created disk images. I got to thinking, realizing that it needed to be full of E5s, so that's what I ended up doing. Once I created the partition layout using HINIT on a disk that was 1. uncompressed and 2. full of E5s, it worked just fine.

Now, the real challenge is to get serial ports working as actual serial ports instead of using emulation inside of MAME.
 
It would be great to try out the emulation with your disk images and guidance - I'd love to receive your material.
Maybe pinching stuff off MAME's serial information for the NCR DMV could help: https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=97011#Post97011

Robert

I'm already setting up a repo on GitHub for those images. I'll be putting up images for all floppy types and a line of "Seagate hard drives" (represented by their geometries only for capacity's sake). I'll even put up the Perl script I used to generate those "disks". I created files full of E5s which can then be piped into chdman as something to populate the images with.

I'll examine that thread in greater detail a bit later. I have an Ampro disk with ZMP configured to run on its second serial port so I can put a lot of my old utilities on my disks. That way I can use Tera Term Pro or similar to move stuff to the machine via ZModem.

Will let you know once I've set this all up!
 
Sounds very interesting. Great work! I have an actual Ampro Little Board (non-plus version) and have been writing a gui-based W10 C# program for accessing Ampro floppy disk Images from .IMD and CP/M 2.2 images in general. It presently loads .IMD files for Ampro CP/M 2.2 as well as other CP/M 2.2 images in raw and simh formats and can extract files from the images using the cpmtools diskdefs as the source for the disk-format specific data (I've tested "amp1" ssdd, "amp2" dsdd, and "ibm-3740" disk definitions). Handling the .IMD file 'compression' and sector maps was pretty straightforward, as was converting it all to a logical CP/M image according to the diskdef.

At least regarding floppy images, I haven't noticed anything odd about the use of 0xE5 in 'strategic places' regarding the CP/M 2.2 file system. While 0xE5 IS the default value used for empty sectors when they're formatted, the only special use in the directory appears to be as the User value that denotes empty/unused directory entries. I.e. at least as far as CP/M goes, it shouldn't care about the fill value for empty sectors. I can see how it would be problem if the directory blocks didn't have an 0xE5 'fill' but software only initialized the 'used' directory entries while assuming the remainder of the blocks were already set to 0xE5. Looking at the Little Board system disk images, e.g. LBSYS-B.IMD unused data areas in the files and boot tracks are typically filled with 0s. Considering CP/M 2.2. doesn't erase data when files are deleted (just deletes the directory entry) there shouldn't be any dependency on what value an unused sector holds.

What 'hard disk' BIOS routines are you using for the Ampro Little Board? Are you using LIttle Board Plus SCSI ROM code?
 
Last edited:
What 'hard disk' BIOS routines are you using for the Ampro Little Board? Are you using LIttle Board Plus SCSI ROM code?

First of all, my apologies for not keeping too close an eye on the thread. I've been a bit busy of late.

I'm using the standard BIOS 3.8 routines that were on the ZCPR 3.3 boot diskette, SYSTEM1.IMD, that's in the collection that Hal Bower put out along with the stock SCSI ROM code that's out there to boot these systems.

As for me, I used to have a non-Plus Z80 Little Board until that got thrown out (I'm afraid), but I had diskettes from those times, though those were in 96tpi format. I'd read them with one of my PCs which has full two-drive floppy support. When I find that the MAME (by way of MESS) had Ampro Little Board support, I wanted to see if I could use those diskettes. Much to my dismay, the driver only knew about DSDD 48tpi drives. One line to the driver was all I needed to add DSQD (a.k.a. DSDD 96tpi) support to the driver, and I could read my images directly.

As for CP/M 2.2's sensitivity to fill characters, it DOES care, actually. I figured that would be the issue when I tried to create virtual hard disk image. I can STAT the drive, and it shows as being unused. I do a DIR and it shows a single entry, which struck me as odd. The INSTANT I try to PIP a file to that filesystem, it says that there is no more directory space, which led me to believe that I should, at the very least, do an E5 fill of the directory space. But depending on how you lay your disk out, you don't necessarily have an idea ahead of time of where your directories will end up being ahead of time, so I figured the easiest way would be to create big files the size of the drive-to-be, then populate the drive images with those files. Works like a champ.

As for those files, I haven't forgotten about that. I have the files ready, but I need to fully flesh out my GitHub repository so then there's information on what files are available and how to use them.

--Katt. =^.^=
 
I didn't realize that you were trying to create an empty filesystem. (The 'strategic places' comment threw me.) Filling the directory blocks with E5 will certainly do that. E5 as the first byte of a directory entry (the user number) is the documented "empty/unused' value. E5 for that plus the following eight bytes of the filename (or a directory entries of all E5) should denote the boundary beyond which all following entries are free (so CP/M doesn't need to scan all possible directory entries when doing a DIR). So filling it all with E5 should give you a completely empty directory for the image. Also, filling any 'boot tracks' with E5 will typically make it look like a non-bootable data disk (at least thats the case on the Ampro floppies). It sounds like you were creating a filesystem image externally without going through a format utility? Looking forward to seeing the files on your git repository.
-- Tom S.
 
P.S. - You mentioned using SYSTEM1.IMD. According to the A74015A AMPRO Z80 Hard Disk Software Users Manual 1985.pdf you may need to SYSGEN a system disk with a smaller TPA in order to have a bootable floppy image that supports a hard disk.
Screenshot 2022-02-24 155551.jpg
 
P.S. - You mentioned using SYSTEM1.IMD. According to the A74015A AMPRO Z80 Hard Disk Software Users Manual 1985.pdf you may need to SYSGEN a system disk with a smaller TPA in order to have a bootable floppy image that supports a hard disk.

Way ahead of you. I ared tee eff em and got things working pretty nicely, actually. I used MOVCPM (rather than ZMOVCPM) to create a 56K CP/M image per the suggestion for an 80MB HDD, then created my hard disk. I even installed NZCOM on one setup, and QP/M (which required me to do a bit of wrangling with SYSGEN to make work) on another (albeit on floppy).

Also, I've finally published my package! It's here on Github.

As for my issues with SYSGEN? When QP/M's installer re-called the stock SYSGEN, much to my shock, it didn't see the image in memory. I probably didn't have to make modifications; just CTRL-Ced out and saved the image at the CP/M prompt, then fed the file into SYSGEN again. I took the leisurely path by modifying the SYSGEN source code. Oh, not just by adding the code, but translating the whole thing to Zilog mnemonics first! My modified sources can be found here, as well as future stuff, also on Github.

--Katt. =^.^=
 
Back
Top