Jump to content

mizapf

Members
  • Content Count

    5,366
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by mizapf


  1. 14 hours ago, Hans23 said:

    I was amazed myself, but I am rather sure:  I installed sockets on the three bus transceiver/latches and I could go back to the faulty behavior by putting the origin 373 back in.

    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.


  2. 28 minutes ago, jedimatt42 said:

    You can't expect people to put 1 instruction in their code for a machine they don't have... That is ridiculous.

    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?

     

     


  3. 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

    • Like 9

  4. 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)

     

    • Like 5

  5. 12 hours ago, Tursi said:

    But MAME is the most accurate emulator, therefore it is Classic99 and real hardware which is wrong. ;)

    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. ;-) )

    • Like 3

  6. 6 minutes ago, Asmusr said:

    Wouldn't a real cart with a 27C010 (128 KiB) also wrap around?

    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.


  7. 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).

    • Like 2

  8. 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.

    • Like 1

  9. 10 hours ago, jedimatt42 said:

    But, I'm guessing the REPL99 doesn't decode the VDP INT from some other sideport bus pin... VDP INT really needs to be sourced from the VDP or lots of compatibility issues are created.. is that a fair assessment?

    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.

    • Thanks 1

  10. 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.

    • Like 2

  11. 13 hours ago, Omega-TI said:

     

    You are right, that IS weird.  I tried it on Overdrive and got 8 seconds.  I'm assuming Classic 99 only uses one CPU and thread?  Imagine what it could do with all six cores and twelve threads.

     

    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.

×
×
  • Create New...