Sorry, the ROM on that page is correct, it's this one that contains an extra 2k. My bad. /Hans On 2021-09-08 07:34, Hans Liss wrote: > There's plenty of information on the clip here: > http://www.6502.org/users/andre/petindex/diag/index.html, including a > dump of the ROM that's identical apart from containing an additional > 2k of "FF" bytes. > > /Hans > > On 2021-09-08 07:11, William Levak wrote: >> >> My notes say that 901447-30 is diagnostic 320350 for the test >> fixture for PETs without a 6545 CRTC. It resides at $9800 in memory. >> It requires a jumper block in place of the keyboard and another >> jumper block on the user port. The test fixture has a clip that is >> clipped over the 6502. The reset button is then pressed and a >> diagnostic begins. >> >> I think I have a description of the jumper blocks on zimmers.net, but >> I don't remember exactly where. >> >> On Tue, 7 Sep 2021, Hans Liss wrote: >> >>> I padded 901447_30_2001diag_0000.bin out with a 2k block and loaded >>> it in VICE at $9000, so that the ROM ended up at $9800, and then ran >>> "sys 38912". This happened: >>> >>> PET >>> >>> So, clearly it's the Diagnostic Clip 901447-30 for PET 2001. >>> >>> /Hans >>> >>> >>> On 2021-09-06 22:35, Hans Liss wrote: >>>> >>>> I used the VICE monitor to load that block into PET video RAM: >>>> >>>> diagnostic 320350g >>>> >>>> a8-a11 bad >>>> >>>> tv ram ok >>>> >>>> i-ram bad >>>> >>>> z-page ok >>>> >>>> a8-adr bad >>>> >>>> stack ok >>>> >>>> remove clip >>>> >>>> /Hans >>>> >>>> On 2021-09-06 22:14, Hans Liss wrote: >>>>> >>>>> 901447-30_2001diag_0000.bin seems to disassemble nicely at $9800, >>>>> and http://mhv.bplaced.net/cbmroms/cbmroms.php lists "901447-30" >>>>> as a "Diagnostic Clip" for PET 2001, to be located at 9800-9FFF. >>>>> Incidentally, the code around $9979 seems to load bytes from $99ce >>>>> to $99d8 to screen memory, so maybe someone more patient than I >>>>> can figure out what it says? I suspect the entire block between >>>>> $9985 and $99d8 is screen text, actually. >>>>> >>>>> 901484-03-2031ro_c000.bin seems to match "901484-03" on the same >>>>> page, which describes it as DOS 2.6 Low for the 2031 drive, to >>>>> load at c000. There's a copy of that ROM on >>>>> http://www.zimmers.net/anonftp/pub/cbm/firmware/drives/old/2031/index.html, >>>>> however, which seems to have nothing in common with this one. So >>>>> that's strange. >>>>> >>>>> /Hans >>>>> >>>>> On 2021-09-06 21:39, Hans Liss wrote: >>>>>> >>>>>> Better link: >>>>>> http://www.zimmers.net/anonftp/pub/cbm/firmware/misc/unknown/ >>>>>> >>>>>> The low count of "a9" bytes in several of these is a sure sign >>>>>> it's not 6502 code. I took a quick look at a few: >>>>>> >>>>>> * 8in-cpm-trbdos.bin is definitely Z80 code (or 8085, perhaps?). A >>>>>> CPM "driver" for 8-inch floppies, perhaps? >>>>>> * 740turbo1-1.bin is also Z80 code. >>>>>> * I suspect ultima-ii-v1-73.bin is also Z80 code. >>>>>> * create-new-base.bin and 40-80-60h.bin seem to be something else, >>>>>> like not program code at all. >>>>>> >>>>>> I found a fairly useful disassembler at >>>>>> https://onlinedisassembler.com/odaweb/, by the way. I tend to use >>>>>> wfdis for 6502 code, but this one has many other architectures >>>>>> and accepts small hex dumps as input. >>>>>> >>>>>> /Hans >>>>>> >>>>>> On 2021-09-06 19:23, Bo Zimmerman wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> Dave McMurtrie contributed a nice pile of PET option rom images >>>>>>> to the funet/zimmers archive _at_ >>>>>>> http://www.zimmers.net/.../computers/pet/other/index.html >>>>>>> >>>>>>> I had no trouble identifying and classifying most of them. >>>>>>> However, there were several that I could either not get working, >>>>>>> properly disassembled,, or just couldn't identify. This is >>>>>>> fairly new to me, so I created a special place for them here: >>>>>>> http://www.zimmers.net/ano.../pub/cbm/firmware/misc/unknown/ >>>>>>> >>>>>>> If anyone out there enjoys digital archeology, I'd ask you to >>>>>>> give a second or third opinion on some of those unknown roms. >>>>>>> It's possible the eproms were just corrupt or unreadable, but >>>>>>> I'd sure like someone else to concur before I throw any of the >>>>>>> images out. >>>>>>> >>>>>>> - Bo Zimmerman >>>>>>> >>>>>>> >>> >> >> wlevak_at_sdf.org >> SDF Public Access UNIX System - http://sdf.org >> >Received on 2021-09-08 08:02:11
Archive generated by hypermail 2.3.0.