mizapf

If you remove the latch (373) completely, you do not get this screen output, I suppose. The 373 is used to store the odd-addressed byte either on write operations (picking up the values of D8-D15 from the CPU) or read operations (picking up the first byte from the 8-bit data bus and then presenting it on D8-D15 to the CPU). While working internally, i.e. accessing the console ROMs or the scratch pad RAM, the multiplexer is not used. Also, it is not used for VDP access (going over D0-D7 directly), but for sound, GROMs, and the I/O port and GROM port (aka cartridge port). I'm trying to simulate that issue in MAME (the fault patterns on Ninerpedia were produced in this way), but I have not been successful yet, so maybe we have a byzantine fault here. It would be interesting to guess which bytes were read when producing the cartridge selection. The colors are from the master title screen, and the character codes are known. Also, there are some parts of the TI logo. I seem to remember this or a similar output, but I am not sure in which context; maybe it was with the Gram Kracker.

Nope. That's called adaptability. Surprise, people might write software that runs on different VDPs, even for the F18A, without owning one. But anyway, I did not understand the intention if Beery's request. If you place BA into 8002, this is actually ROMPAGE, right? It hides the GeneveOS DSR. So where is the advantage over entering GPL mode with ROMPAGE?

"$" is a normal thing for Unix (Linux) users (as is # for a root shell), although I also redefined my prompt, so it looks like "[email protected]:~/mame>".

Does it happen for GROM-only cartridges as well (e.g. Hunt the Wumpus, Adventure, Amazeing, Car Wars, Disk Manager)? And what about ROM-only cartridges (like Atarisoft titles, e.g. Defender)?

Since 0.227 is still not out, I'll give you an intermediate release of MAME in WHTech. It not only contains the above mentioned Horizon works but also the fixed paged378 cartridge type that allows you to run petee's Copper demo. You just need to unpack the zips over your current installation. Linux (Ubuntu ≥ 20): https://ftp.whtech.com/emulators/MAME/ti99/linux/mame20201218b_ti99_linux64bit.tar.gz Raspbian: https://ftp.whtech.com/emulators/MAME/ti99/raspbian/mame20201219b_ti99_raspbian32bit.tar.gz Windows: https://ftp.whtech.com/emulators/MAME/ti99/windows/mame20201218b_ti99_win64bit.zip

OK, paged378 fixed and committed in MAME. With the next release you'll see the full copper demo. Edit: If you don't want to wait, you can find the Windows build at https://ftp.whtech.com/emulators/MAME/ti99/windows/mame20201218b_ti99_win64bit.zip. Download it and unpack it over your MAME installation. I'm going to prepare more builds in short term. Linux: https://ftp.whtech.com/emulators/MAME/ti99/linux/mame20201218b_ti99_linux64bit.tar.gz (Ubuntu ≥ 20)

If reality were to comply with MAME, I'll just start off now with patching out that damn pandemic virus. 🙂 (As for the issue above: The paged378 mode was my interpretation how this cartridge type works, but I never had one in my hands. I'm still struggling to get the omniscience perk. )

OK, it runs on MAME if I add the page wrap. Also, I ran it on MAME 60Hz and 50 Hz, and both differ by the run time only: 120 sec vs. 144 secs. So may I assume that the paged378 cartridges have a page wrap for smaller ROMs?

I am not sure about that, and have to rely on what the owners of the real thing observe. If a single chip is used, we'll get a wrap-around, but not if several chips are used because the chip select may get lost. Either way, it is not a big deal to fix it in MAME.

I can well imagine that they changed the wording in German later on and did not check the translation. The differences are not really big, but in the case of the REPL99x I missed a notice about the required wire in the translation. They said the VDPINT had to be "connected", but without further detail.

I confirm, in MAME, only the first seconds show correctly (until 0:08 in the video), the first three stripe displays. I cannot tell why it fails after that because I don't know the technique behind it. The 9918 emulation in MAME has been known to be quite precise, considering that the previous demos like Don't Mess with Texas run flawlessly, but I am not the author of the 9918 emulation. @PeteE Maybe you can provide a simple sample program that should show a particular behavior so that I can test it, and we can find out the issue behind it. Edit: It fails because the program crashes; I am getting this error: [:gromport:single:cartridge] Set ROM page = 30 (writing to 603c) [:maincpu] ** 601a: Illegal opcode 0000 which means that the cartridge space is not correctly mapped. I used paged378 for it, that is, writing to 6000 + i*2 maps page i into 6000-7FFF (for i=0..63). Everything works well until this switch. In fact, page 30 is far beyond the cartridge space (128K).

The English translations of the SNUG manuals do not convey 100% of the German version, as I noticed; some side comments were lost which may be interesting. I already planned to add a citation in the above post when I noticed that the German original was already formulated ambiguously. Writing specs is a proper art.

The MAME rpk of RXB 2020. rxb_2020.rpk

The EVPC1 needs two cables: GRMCLK and VDPINT. With the REPL99x (see the docs where SNUG state that it can be used with EVPC1), the GRMCLK cable is not used anymore, but the video interrupt must still be led to the console via a separate cable because the EVPC1 does not latch its own video interrupt, so it cannot tell whether it was the originator of the EXTINT. This was changed with the EVPC2 which also has a modified DSR. Hence, the REPL99x does not need either cable with the EVPC2. As I understood it, apart from leading the signals into the socket, and from terminating open bus lines, the REPL99x just provides an oscillator for 447 KHz (GRMCLK). So what I emulated in MAME is the EVPC1 with the VDPINT cable and the oscillator in place of the VDP, that is, the REPL99x. How else should I have done it? Without the REPL99x, I would have needed two cables, and put the oscillator on the EVPC1. This should not be different from the point of using. I don't think the REPL99x has to do with VDPINT/EXTINT, but I may have misunderstood it.

I implemented the EVPC in MAME with a separate VDP-INT wire plus the REPL99x.

Maybe have a look at the docs from SNUG: https://www.s-n-u-g.de/evpc/index_en.php The relevant docs should be in the section EVPC.

I have a MBX system here, yet never tested, and I do not have any schematics or dumps. I agree with @pixelpedant, it is questionable what I could reasonably emulate in MAME, at least with justifiable efforts (and prospect of being useful). I still have so many open sites in MAME that I currently don't want to promise anything.

I'm using a script like this: STDEA: TIMODE ECHO Loading GPL Interpreter & Standard EA GPL EA and run it as &STDEA. (Ampersand causes a warm reboot.)

Why are you using timode for the autoexec? Doesn't this take away resources for native applications? (I'm using timode only in scripts that launch GPL mode, or for EXEC.)

Parallel cores and threads are only useful when the task can be parallelized. As for MAME, the core gurus have not managed to get this working or even conceived after 20+ years.

PFM also makes use of two CRU bits: https://www.ninerpedia.org/wiki/Programmble_Flash_Memory_Expansion

That is, you'd check the ID and decide for a particular protocol to work with the chip? In that case, I would have to implement this as a variant of the existing emulation. Hopefully we don't have too many compatible chips with different IDs.

You already showed the mame.ini file. Look for a line starting with "video". What is the value written after video? You can change the mame.ini file at that line, or you can launch MAME with the command line argument "-video... ".

What value has the "video" setting? What happens if you use "-video opengl" or "-video bgfx" or "-video soft"?

Is it functionally equivalent to the AT29C040A? (block size, capacity, protocol) If so, there is no need to implement the Winbond chip.