mizapf

It seems as if we'll have a clear sky during the next hours. I'll give it another try.

We should consider to set up a folder structure on WHTech where we can collect all these works. The initial structure is at https://ftp.whtech.com/Geneve.new/. I could add "Software" as a generic placeholder, and on the next level, we can sort by topic or by author. As I expect that people look for software by topic rather than by author, sorting by topic makes more sense. DSK format should be preferred for easy use in the Geneve emulation in MAME.

I'm a bit confused about the version number - do you mean "Boot ROM 0.98" (vs. 1.00) or MDOS / GeneveOS (from which I never saw a version earlier than 1.14 that I got with my machine)?

The Moon is still here. Pictures taken on Nov 27, 2020 21:30 CET, almost full phase; Meade LX200 with focal reduction f/6.3, Sony a58 attached. Exposure 1/100 s, ISO 100. Result of 16 stacked shots. When I noticed that the left edge was blurred, I went back to the telescope to do some more shots, but haze started to come in, and the telescope already became moist on all sides. So that's it for today. I suppose the blur already resulted from moisture that gathered on the corrector plate.

Does Geneve count?

I guess the intention was to use EXPMEM2 to temporarily save the program, then remove all disk buffers, and load it from there. Would have worked, had there not been the disk access in the program.

I tried the instructions on Gameshelf in MAME, and failed as well; I am getting a corrupted program in TI BASIC, just like @xxx reported. The descriptions cannot possibly work this way. The program is very long and does not run with CALL FILES(1). Apparently, the author suggests to remove all disk buffers (using CALL LOAD). Before I tried it, I already suspected that this will likely fail, because you kill all disk buffers, but the game does a disk access right at the beginning. Killing the disk buffers means that the BASIC program will be located at the RAM top, and the floppy drive overwrites the program. Classic99 seems to be right here.

Adding to your posting on the other thread: Apart from the typo, "ccdcc" is the original Corcomp controller with the WD2793 chip, while "ccfdc" is the revised version with WD1773.

i = binary powers KiB = Kilo(binary)byte = what we used to call KB earlier; 1 KiB = 1024 byte MiB = Mega(binary)byte = 1024 KiB 1 KB is now 1000 byte (which would be the ideal case, but it is clear that not everyone will follow that recommendation) https://en.wikipedia.org/wiki/Binary_prefix

OK, then Chris @Shift838 may help you better. You could, for a start, try the command line first, just to make sure everything is in place.

Please post the command line that you tried.

MAME does not use the "bin" cartridges but either the RPK or ZIP files. Never unzip a cartridge ZIP file (apart from the all_carts.zip, which contains all ZIP cartridges). We have them all on WHTech, https://ftp.whtech.com/Cartridges/MAME mame ti99_4a -cart blasto (no .rpk, no .zip, no .bin in the command line) Put the ZIP cartridges in your roms subdirectory. Disks will only work when you attach the hardware. You must plug in the Peripheral Expansion Box into the I/O port, and a disk controller (e.g. DDCC-1) into one slot. mame ti99_4a -ioport peb -ioport:peb:slot8 ddcc1 -flop1 somefloppyimage.dsk

What I can imagine is that the BwG controller (by its GAL) was modified to pretend to be a Corcomp. It would suffice to turn off the DSR ROM when CRU bit 11 is set. The Boot EPROM only checks whether setting bit 11 has any effect, i.e. it reads 4000 again, and when there is no AA anymore, it sets the Corcomp flag. The actual ROM contents are less relevant, as the boot EPROM does not pass control to it.

Stay informed about MAME progress related to the TI platform on my pages https://www.mizapf.de/en/ti99/mame. New features, bug fixes etc.: https://www.mizapf.de/en/ti99/mame/changes The version you mentioned must be about 20 years old, much earlier than I started contributing, so I really cannot help you with that.

Announcement: Release 0.227 will be delayed until December. There are some technical reasons, especially unstable drivers; see https://www.mamedev.org/?p=489. With a tiny bit of pride I dare say that our TI drivers are not part of the problem. 🙂 Release 0.227 will provide you with a new Horizon emulation which allows for all the configuration options of current 4000B cards. In the meantime, I managed to set up the MSYS2 build environment on Windows. This means that I can now build MAME releases for Windows at any time, too. As with the Linux and Raspbian versions, I restrict the set of drivers to the following ones: TI-99/4A (Eur/US), SGCPU (aka 99/4P), TI-99/8, TI-99/2, Geneve, evmbug (Stuart's Breadboard Project), Powertran Cortex, TM990189, Tomy Tutor, CC40. This reduces the MAME executable's size by more than 50%. You will find the MAME releases on the FTP server of WHTech in the path /emulators/MAME/{full | ti99}/<operatingSystem> The "ti99" subtree contains the above-mentioned restricted MAME versions; the "full" subtree offers all drivers (you still need their ROMs, of course). The official builds have a release number in their name behind the prefix "mame", like "mame0226...". The interim releases have a date in their name behind the prefix "mame". The current file that I uploaded is called "mame20201121b_ti99_windows64bit.zip". The "b" indicates that this is a binary package. The "ti99" in the name stands for the restricted release, and the rest is the operating system. Whenever I believe that the current state is stable enough for use, I will upload such an interim version (and take away older ones). Typically there should only be such versions for the current month. Within this package you will find my magic cygwin script "mameprep_cygwin". After unzipping the package and storing the contents in some folder on your drive, you can invoke this bash script in cygwin which automatically pulls all ROMs, important disks, a boot HD for the Geneve, and more from the FTP server, sets up start scripts and stores them in a folder on your desktop. When it is finished, you are ready to go; maybe you want to copy your own disks from your old installation into this new folder. Chris is preparing his OoeyGui tool to adapt to this structure on WHTech; it already incorporates the mameprep_cygwin features so that you do not need to install Cygwin and run my script if you take OoeyGui.

@OLD CS1, could I send you a dump program that creates a disk dump of your boot EPROM and the BwG ROM? Just to make sure whether we have a patched version somewhere. In fact, if the BwG is detected as a Corcomp controller, it should boot the Geneve, because both are using the same controller chip (WD1793). The only problem is when the BwG is falsely detected as a TI disk controller, because the FD1771 controller has inverted data lines, so every byte you get or send to it must be INVed, and this must fail for the other chip, I am quite certain. Yes, and 0.98 is the usual "Swan" release with black border.

Klaus, you can nicely see the performance effect of 50Hz/60Hz when you choose the drivers ti99_4a vs. ti99_4ae in MAME*. I confirm that I never knew what people talked about with this "rainbow" effect, since it was not visible on PAL. MAME contains a lot of BGFX filters; I don't know whether one of these tries to mimic the NTSC color issue. *Concerning Parsec, this difference is so obvious that I get about 1/3 points less with 60Hz; also, in 60 Hz, the three lifts actually make sense, while I never had a use for lift 2 in 50 Hz.

No, nothing to be sorry, I'm happy to hear someone else has been actually using it! 🙂 I had an Amiga in those times as well, and from there I got the idea to make use of the MID interrupt. I always wondered why this feature was disabled in MDOS / GeneveOS. Just a few days ago I noticed that DM-1000 which I was using with the Horizon emulation has a minor bug; it runs over a 0000 at some point. This would have caused a MID with the Geneve, while it would not have been noticed with a TI. So maybe the authors of MDOS considered this to cause more trouble than benefit.

OK, I had a closer look at the boot EPROM (0.98). It does the following check: - Look for a card with the device "HD". If found, try to load SYSTEM/SYS from it. (Horizon RAMdisk) - Look for a card with the device "WDS". If found, try to load WDS1.DSK1.LOAD/SYS. If that fails, try DSK1.LOAD/SYS. If that also fails, error out. (Interestingly, this is the only device that is rompaged and that is allowed to use its own DSR.) - Now try CRU >1100 only. Check if there is a card; if not, error out. - Try to write a word to >5000; if that succeeds, we have a Myarc floppy controller (DDCC-1). - If that failed, set CRU bit 11. If we have a CorComp, this would map the upper bank into >4000. - If there is still AA at >4000, it is a TI FDC, else it is a CorComp. The point is that a BwG ends up to be detected as a TI FDC. However, it uses a different controller (WD1793 instead of FD1771). The FD1771 controller has inverted bus lines, so every byte must be inverted before writing or after reading. This is wrong for the WD1793. This would again prove that the BwG cannot boot the Geneve, at least with the 0.98 boot EPROM. I have to concede that I am running out of ideas now ... 😕

Did that happen to be my Guru meditation? 🙂

I'm starting to get some doubts. I just had a look at the boot EPROM (comments from me): 0864: MOVB @>5FF0,R4 Get status from controller 0868: INV R4 Invert it (FD1771 has inverted bus lines) 086A: JLT >0874 First bit set = NOTREADY 086C: COC R8,R4 R8=0200; DRQ bit (mirrors DRQ output) 086E: JEQ >0882 If set, DRQ output=1; there is a byte 0870: COC R9,R4 R9=0100; BUSY 0872: JEQ >0864 If set, command is executing 0874: JMP >07CA Error 0876: MOVB @>5FF0,R4 see above 087A: INV R4 087C: JLT >0874 NOTREADY 087E: COC R8,R4 0880: JNE >088C DRQ 0882: MOVB @>5FF6,R4 Pick up byte from register 0886: INV R4 Invert it 0888: MOVB R4,*R3+ Copy it into memory 088A: JMP >0876 088C: COC R9,R4 BUSY 088E: JEQ >0876 0890: JMP >082E Despite my first guess, the boot EPROM is actually polling the DRQ state. This would mean that it does not rely on the READY trap - otherwise, it would suffice to execute the instruction at 0876 or 0882 (as done in the original DSR). One thing that just came to my mind: 1. When code is executing in on-chip RAM, the READY line is always ignored. This is not on-chip RAM, so it's not the point. 2. The original DSR assumes that logical addresses 8300-83FF are mapped. As it seems, one SRAM page is mapped there, so this should be good either. (two things) So why didn't they rely on the card hardware? The problem is that the READY line is fed into the Gate Array first, then into the PAL, then into the CPU. 3. The boot EPROM (I'm always talking about 0.98, just to be clear) probes different cards. I see references to Myarc cards, the original TI controller, and Corcomp. I have to check what it does when the BwG is plugged in. If the READY trap does not work, my considerations from the previous post are probably irrelevant.

Well ... these are the frustrating moments of emulation. 😞 I never got the BwG to run with the Geneve emulation. It does run flawlessly with the TI-99/4A, and all other controllers including the DDCC-1 are working, but not the BwG with the Geneve. Of course, when I first observed these issues, I did a lot of debugging and error tracking, and finally I could say it was obvious and *provable* that the BwG would not run! 🙂 So let's forget reality for a minute. I'll detail my thoughts below. Maybe someone can tell me where I am wrong. (The others may learn how a disk controller works. ) I got the schematics of the BwG and checked how it worked. This is the relevant part that I attach to this message. It shows the "READY trap". From left to right: - READY is pulled down when U7B outputs a 0. As it is an OR, this means that all inputs must be 0. - The lower violet line is the "SBO 2" line. When you execute SBO 2, the bit is first inverted, then routed to U7B as a 0. Hence, without SBO 2, there is no lock. - The blue line goes to U23B (NAND). It must also be 0, which means that all inputs must be 1. - One of the inputs is A15. Thus, we must have an access to an odd address, and it must look like ...7 or ...F (because of A13=A14=1). The data register of the WD1773 is mapped to 5FF6 (read) and 5FFE (write). What we don't see here (clipped by me) is that the other address bits are checked to be 5FF... - Pin 9 of U23B gets its input from U23A (configured as an inverter) and then from U7A. To be 0, all inputs of the OR must be 0. One input is from U24A, the motor monoflop. This means that if the motor stops spinning, the lock is immediately released. The other two are IRQ and DRQ from the controller chip WD1773. Both are high active; if some exception occurs, IRQ will be asserted, and when a data byte has been gathered and is now available in the data register, DRQ is asserted. In both cases, the lock is released. Now we have a look at the DSR: 8300: MOVB @>5FF6,*R2 8304: DEC R6 8306: JNE >8300 8308: RT This is the typical loop that we also have in the other WD-like controllers (not in the HFDC; it does not need a READY control, as it uses its on-board RAM to let the controller push the data into it). This part has been copied to 8300 before the operation. In the first line there is a byte read from 5FF6. This is a even address, so it does not set A15 to 1. However, the TI-99/4A always reads the odd address first, then the even address. It reads 5FF7, and locks up. Meanwhile, the controller gets a byte, signals via DRQ that the byte is lying in 5FF6. This releases the READY line, the CPU continues, reads 5FF7 (which is masked away from the controller at another part not shown here), reads 5FF6, and so gets the byte. R6 is counted down until there are no more bytes to come (we are reading a whole sector). R2 is actually >8C00 (VDPWD), so each byte is copied to VDP memory. Now, as I said, the emulated BwG fails to work with the emulated Geneve. This is perfectly understandable with the explanation above: The Geneve only does single byte accesses, so it does not access 5FF7, and the lock is not activated. Instead, it spins down all 256 iterations immediately. Sometimes you are really glad when you've found a plausible explanation after all. But why on Earth are there BwG that are working with the Geneve?? One thing could be that there was a revision of the board. It was not necessary to wait on the odd address; the even address 5FF6 would have done, too. This is the way how it is done in the TI FDC and the DDCC-1. I do not know why the SNUG people went for that way in the first place. I thought it could suffice to cut the A15 line at U23B and to pull it up. In that case, the lock would have been activated twice, for 5FF6 and 5FF7. However, when the Geneve reads 5FF6, this also clears the DRQ, and the lock could be activated again, so it could be trapped. The TI-99/4A would not have this problem, since it first reads 5FF7, which does not affect the controller. I tried it in MAME, but it did not have an effect (which is less than expected); need to continue working on that. Or maybe the DSR was modified. If the MOVB were replaced by a MOV, the Geneve would also do a two-byte operation, triggering the trap. I'll keep you informed. Until this is settled, I keep the BwG removed from the possible choices for a disk controller for the Geneve.

You need to get three states (for the cycle plus two wait states). It seems to me that this 74ls194 is a shift register that shifts a bit at QA, QB, and when it reaches QC, it is fed back to the first position, inverted.

This is a bit short as an explanation. There is no fatal hardware deficiency, otherwise GeneveOS would not be able to use the controllers by its master DSR. I once encountered an interesting issue with the BwG controller in the emulation. Maybe this was fixed later, as some people claimed that the BwG controller worked with the Geneve. With the WD177x/WD179x controllers, you don't have the luxury of having a cache RAM as the HFDC does. Thus, you must pick up every single byte that has been read by the CPU. Usually this is solved via the READY line: Doing a MOVB @>5FFx,Rx arms the "READY trap" which locks the CPU inside this operation by pulling down the READY line. This is until the controller signals a DRQ (data request), indicating that a complete byte has been read. In that moment, READY is released, the MOVB instruction continues and gets the byte from the data register. This is repeated for every byte until the command has completed. With the BwG there is an interesting issue: The READY trap is triggered by the odd address (e.g. 5FF9, not 5FF8) by the circuitry. This can be seen as the A15 address line must be 1 to enable the lock. With the TI-99/4A, you should know by now by our discussions on this forum that a MOVB is in fact the same as a MOV, since the TMS9900 cannot access single bytes. Only inside the CPU is the byte operation actually peformed differently. So a MOVB @>5FF8,R0 first does an access to 5FF9, locks the CPU there, then waits for the release, and then gets the byte in the second read (the even address 5FF8). Now for the issue on the Geneve: The TMS9995 does real 8-bit accesses to external memory. When you do a MOVB @>5FF8,R0, the address 5FF9 is never seen on the bus, and the READY trap is not operational. From the citation above, it seems as if the READY trap concept did not work in general on the Geneve, but this cannot be true, since this would mean that the TI controller cannot work at all. I don't think you can somehow emulate the READY trap by constant polling. The answer to this question lies in the code in the boot EPROM. If I find some time, I can check it more closely.

I think what is difficult to imagine for many people less acquainted to the TI-99/4A is that this machine came with only minimal RAM (256 byte), and instead, used the video RAM to store the BASIC program. Hence, many ideas for the unexpanded console that would be applicable to most other platforms turn out to be just unfeasible or - in the case of Playground - as a clever, yet limited hack. Our community had to learn quickly, right from the start, that the plain console is rather uninteresting.