|
Joined: Mar 2013
Posts: 344 Likes: 3
Senior Member
|
Senior Member
Joined: Mar 2013
Posts: 344 Likes: 3 |
de-skeletonized ms0515.cpp -- CPU is a clone of T11, video controller is Spectrum-like and there's a few ported (or maybe recompiled) games, f.e. Pull request soon. Shout out to Dr. Titus for being the first to emulate this machine in EmuStudio. I was wondering, does this still work or has there been a regression? I found the dsk image which supposedly includes Saboteur 2 among other games but it seems to get stuck trying to auto-boot it.
|
|
|
|
Joined: May 2012
Posts: 568 Likes: 10
Senior Member
|
OP
Senior Member
Joined: May 2012
Posts: 568 Likes: 10 |
Yes, there's been a regression after commit 6ea69b0ed967c898911d51fba9b6084b506e9849
Date: Thu Mar 30 10:22:58 2023 -0700
machine/wd_fdc.cpp: Dont clear DRQ on LDB/INTR, and fix spurious READ TRACk/ADDR FM mark syncs. (#11041) [Peter Phillips, Tim Lindner]
|
|
|
|
Joined: Mar 2001
Posts: 17,215 Likes: 234
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 17,215 Likes: 234 |
Which of the changes did it? I would assume the second one?
|
|
|
|
Joined: May 2012
Posts: 568 Likes: 10
Senior Member
|
OP
Senior Member
Joined: May 2012
Posts: 568 Likes: 10 |
6ea69b0ed967c898911d51fba9b6084b506e9849 broke it 60ced2cb0c9c4ae9a2f6a65ff50b07fecee78f4c "wd_fdc: Drop DRQ when ending a normal command" fixed it e992c500ccf306f7245158d6d5ee97661211dccf "wd_fdc: IRQ/DRQ corrections" broke it again
|
|
|
|
Joined: Feb 2004
Posts: 2,597 Likes: 300
Very Senior Member
|
Very Senior Member
Joined: Feb 2004
Posts: 2,597 Likes: 300 |
6ea69b0ed967c898911d51fba9b6084b506e9849 broke it 60ced2cb0c9c4ae9a2f6a65ff50b07fecee78f4c "wd_fdc: Drop DRQ when ending a normal command" fixed it e992c500ccf306f7245158d6d5ee97661211dccf "wd_fdc: IRQ/DRQ corrections" broke it again Can someone open a proper issue on GitHub for this?
|
|
|
|
Joined: Dec 2015
Posts: 171 Likes: 11
Senior Member
|
Senior Member
Joined: Dec 2015
Posts: 171 Likes: 11 |
I was able to test the ms0515 regression myself, and found a likely cause. The current FDC emulation doesn't drop DRQ until a new command is *committed*, which is over a dozen microseconds after it is written. Meanwhile, a DRQ from the old Read Address command has not been serviced, so the CPU code polls and finds that right away, just about a microsecond before its Read Sector command is committed, and copies a spurious data byte (which should actually be part of the CRC) to address 0, throwing the rest off.
|
3 members like this:
shattered, ICEknight, exidyboy |
|
|
|
Joined: May 2012
Posts: 568 Likes: 10
Senior Member
|
OP
Senior Member
Joined: May 2012
Posts: 568 Likes: 10 |
De-skeletonized uknc.cpp shows signs of life: This machine was standard equipment in many computer classes in high schools, so there's plenty of educational software and games. There are two existing emulators, one of those is open-source ( https://github.com/nzeemin/ukncbtl). Working on a forward port of this code; one weird trick this hardware does is a byte-wide hookup of a 8255 to 16-bit bus without using byte-wide instructions, not sure how to handle that in MAME. 8255 is mapped at 177100-177103 and the code goes like this ( https://raw.githubusercontent.com/shattered/retro-bios/master/ms0511-uknc/ROM5.lst):
136004$:MOV R5,-(SP)
MOV SP,R5
MOV #174,177103$
MOV #200,177102$
JMP 136056$
and so mem_mask in write handler is 0xffff in both cases:
[:subchan] ':subcpu' (136016) W 177102 <- 000174 & 177777
[:subchan] ':subcpu' (136024) W 177102 <- 000200 & 177777
|
|
|
|
Joined: May 2012
Posts: 568 Likes: 10
Senior Member
|
OP
Senior Member
Joined: May 2012
Posts: 568 Likes: 10 |
byte-wide hookup of a 8255 to 16-bit bus without using byte-wide instructions, not sure how to handle that in MAME. read/write_unaligned instead of read/write_word deals with this. Altpro SMK512 firmware for the BK0010 also uses this trick to map ATA register file.
|
|
|
|
Joined: May 2012
Posts: 568 Likes: 10
Senior Member
|
OP
Senior Member
Joined: May 2012
Posts: 568 Likes: 10 |
Another quirk that I'm not sure how to deal with. bk0011m onboard memory layout is:
map(0000000, 0037777).ram().share(m_ram[0]);
map(0040000, 0077777).view(m_view1);
m_view1[6](0040000, 0077777).ram().share(m_ram[0]);
...
m_view1[5](0040000, 0077777).ram().share(m_ram[7]);
map(0100000, 0137777).view(m_view2);
m_view2[6](0100000, 0137777).ram().share(m_ram[0]);
...
m_view2[5](0100000, 0137777).ram().share(m_ram[7]);
m_view2[8](0100000, 0137777).rom().region("maincpu", 0);
m_view2[9](0100000, 0137777).rom().region("maincpu", 040000);
m_view2[10]; // asserts ROM3 bus signal to access ROM on slot device
m_view2[11]; // asserts ROM4 bus signal to access ROM on slot device
map(0140000, 0157777).rom().region("maincpu", 0100000);
map(0177660, 0177663).rw(m_kbd, FUNC(k1801vp014_device::read), FUNC(k1801vp014_device::write));
... I/O page continues ...
SMK512 is a combo MPI (QBus) device (floppy, ATA bridge, memory expansion), and needs to take over some of the onboard memory ranges some of the time (there are 8 layouts). Currently I'm using install_rom/ram from within the slot device like so: m_bus->program_space().install_ram(0100000, 0176777, &m_ram[m_offset]); // layout Hlt10 This deletes the mapping for m_view2, and reinstalling it (after switch to a different layout which does not take over range 0100000) does not work (fatal error "Collision on multiple init_handlers calls"). Technically, when SMK512 takes over range 0100000, it forces the host to "m_view2.select(11)", but I don't see a quick and easy way to access memory on the slot device this way. (Without adding read/write accessors and bus glue to handle ROM4 signal ...)
|
|
|
|
Joined: Jun 2001
Posts: 520 Likes: 33
Senior Member
|
Senior Member
Joined: Jun 2001
Posts: 520 Likes: 33 |
m_view[11] is a derivative of address_space_installer (as spaces are too). Pass that to your slot device to call install_ram on.
|
|
|
3 members (Cpt. Pugwash, 2 invisible),
196
guests, and
1
robot. |
Key:
Admin,
Global Mod,
Mod
|
|
Forums9
Topics9,320
Posts121,923
Members5,074
|
Most Online1,283 Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|