New MAME release

[ralphb]

When did the mamedevs actually decide to split BIOS files into ROM and BIOS folders?  Is there a slight chance to change this when arguing otherwise?

 

While the TI BIOS files are covered, of course ?, it is very inconvenient to update your BIOS files by having to download all MAME ROMs again and again. ?

[+hloberg]

playing around with the 99/2 with the memory expansion got a odd ,error?

to see how much memory you have left in 99/4a BASIC you can run this little program:

1 A=A+8

2 GOSUB 1

you eventually get a MEMORY FULL error then print A gives you the memory left. If run the same program on the 99/2 with no 'memory expansion' get about 2k in A. But if you run that same BASIC program with the expansion the program never stops.

[+mizapf]

No guarantee for using the memory expansion on the 99/2. It is very likely that the operating system of the 99/2 has a good deal of bugs in it, and I don't know if anyone has a real 99/2 with this expansion to check.
 

Concerning ralphb's question, I've been discussing this with him by private message because I did not understand his question.

[+hloberg]

53 minutes ago, mizapf said:

No guarantee for using the memory expansion on the 99/2. It is very likely that the operating system of the 99/2 has a good deal of bugs in it, and I don't know if anyone has a real 99/2 with this expansion to check.
 

that's what I figured about the 99/2 thus the ?

On the other hand the 99/8 seems to work well. thx.

[globeron]

@mizapf   I saw several forum regarding the mouse,  I changed it in mame.ini to set mouse to 1,

but it seems I cannot get my USB (wireless) mouse to work with MYART.  Do I need to do another setting?

[+mizapf]

Did you include "-colorbus busmouse" in your command line?

[globeron]

6 hours ago, mizapf said:

Did you include "-colorbus busmouse" in your command line?

 

Thank you, I did not (was not aware of it)

and I also had to change the input controls in MAME.

 

mame.ini settings:

mouse                         1

multimouse                  1

mouse_device              mouse

ui_mouse                     1

 

(used F2 (reconfigured for UImode, normally scroll lock) and then TAB)

 

 

 

 

 

 

The mouse now also works with ABASIC  -  Global War program.

https://atariage.com/forums/topic/325126-lotz-o-games-hd-for-geneve/?do=findComment&comment=4911754

 

 

 

Edited September 26, 2021 by globeron

[+mizapf]

The reasons for me to add this command line switch:

 

1. Maybe someday I can add a lightpen.

2. In Windows the mouse is captured automatically, but you don't always need the mouse in the emulation.

3. By defining a pluggable slot, this is now consistent with other slots like the joystick port.

[+9640News]

Michael,

I know I saw an earlier note you had done some work to get the SCSI interface working.  Has that been implemented yet?

Beery

[+mizapf]

Not ready yet. I'm still working on the PDMA feature, and in particular the word transfer. As it turned out, this may force me to reimplement the datamux emulation, because right now, it is not able to process the external (P-Box) READY line at the odd address byte. As all other cards only use even addresses for READY-controlled access, this was not a problem until now.

 

So I am currently back into analysing the datamux in the console, and there I am somewhat in trouble because I just cannot derive the timing diagram of the CPU read operation; I'm always short of two waitstates. That is, when I build the circuitry in a tool like Logisim, and I send pulses to it, I am getting 4 cycles instead of 6. If I don't find the solution in the next days, I'll post the issue here.

 

(Out of despair, I already checked the real TI main board with its schematics, but they seem to match.)

[Tursi]

6 hours ago, mizapf said:

So I am currently back into analysing the datamux in the console, and there I am somewhat in trouble because I just cannot derive the timing diagram of the CPU read operation; I'm always short of two waitstates. That is, when I build the circuitry in a tool like Logisim, and I send pulses to it, I am getting 4 cycles instead of 6. If I don't find the solution in the next days, I'll post the issue here.

Timing diagrams captured from real hardware: https://docs.google.com/document/d/16seTZczVk_We9FNbwMp2q5hLOKgwkVJitHrRKoH4VAo/edit

Bunyard book talks a lot about the multiplexer: bunyard-hardware-manual-for-the-texas-instruments-994a.pdf

 

You probably have all this already, but just in case there's a clue

 

[+mizapf]

Thanks! This could indeed help me understand the issue. I have Bunyard's text already, but I did not remember to have a look into it. The current emulation in MAME relies on the fact that there is a counter, and how long it is supposed to count, but as I said, I may be in a situation where I need to precisely understand what happens here. This is particularly true, as I was a bit sloppy at that point, combining the external READY *behind* the databus multiplexer, and not *before*.

[+mizapf]

I found my problem: While simulating the wait state generator, I lowered the /MEMEN line before ø2 goes high. In fact, at the rising edge of ø2, /MEMEN is still high; it falls within the high time of ø2. The counter is triggered by the rising edge of ø2, but is kept reset during /MEMEN=H. So I started it one cycle too early. Also, I was not missing two wait states but only one: The state of the READY line is sampled at ø1 going high, which means that READY may well go up with ø2, and this will only be noticed in the next turn. And then, READY=H during ø1=H means that the data bus has valid data in the next cycle.

 

The signal chart in the TI-99/4A console technical data booklet is correct (Figure B: I/O read timing), with the exception of the READY signal. It should fall with the falling /MEMEN signal in clock cycle 1 and rise after the raising edge of ø2 in CC5.

 

In fact, in MAME I did not emulate the four clock signals but pretended there is only one. This works as long as the order of signal changes is preserved.

 

(Edit: I'm lying. In fact, I actually implemented it correctly (feeding the external READY into the counter), but this was obviously so long ago that I didn't even remember it.)

[+9640News]

Does this mean the PDMA feature has been resolved, and SCSI capability is nearing release?

[+mizapf]

I am pretty sure I won't let the completion of the SCSI system go unnoticed in this forum.

 

[kl99]

thanks for all this hard work mizapf. this is wonderful preservation efforts on our beloved machines and accessories

[+mizapf]

If you know Logisim (a Java-based tool for creating and simulating circuits), here is my file, now cleared of all glitches and working as expected. This is the portion of the databus multiplexer that controls READY, A15, and /WE.

 

http://www.cburch.com/logisim/download.html

datamux.circ

Edited October 10, 2021 by mizapf
Added a screenshot

[+arcadeshopper]

Looks like some major ui updates are coming in the next release

Sent from my LM-V600 using Tapatalk

[+mizapf]

I just registered a new domain name, "ninermame.org", which will be used for MAME information related to the TI-99 family. I thought it would be better to get an own domain for this, rather than referring to it via my personal website only. The name has been chosen to be similar to the ninerpedia.org domain.

 

I got a permission by the owner of the MAME trademark for using "MAME" in the domain name.

 

It may take a few days before the domain is officially accessible.

 

I still have to figure out whether I will use Mediawiki or Joomla for the ninermame website. I got experience in both of them, ninerpedia.org is a Mediawiki site, while mizapf.de is Joomla-based.

 

Edit: Any preferences from your side? Should a website about the TI MAME emulations (including setup, tips and tricks, documentation) be more like a Wiki (like Ninerpedia) or like a content-managed website?

[+mizapf]

Getting closer ...

Still have to do some tests, especially writing. PDMA ON makes DIR lock up (in SCSIC7 loop in SCSI_S).

[+mizapf]

@InsaneMultitaskerIs it an expected effect that a WHTech SCSI card crashes for PDMA ON? I noticed that GeneveOS turns on Block Mode, which is not implemented in the WHTech SCSI card (according to the schematics).

 

I'm afraid that due to numerous fixes, daughterboards etc. there is a whole bunch of cards by the same name which behave all differently...

 

BTW, I suggest to rename the command PDMA to BDMA (Block DMA).

[+dhe]

>I'm afraid that due to numerous fixes, daughterboards etc. there is a whole bunch of cards by the same name which behave all differently...

 

Do you have one to test against - or are you modeling based upon software + Schematics?

 

I have one in my geneve pbox and just got scsi2sd working with MDOS 7.3

[+InsaneMultitasker]

2 hours ago, mizapf said:

@InsaneMultitaskerIs it an expected effect that a WHTech SCSI card crashes for PDMA ON? I noticed that GeneveOS turns on Block Mode, which is not implemented in the WHTech SCSI card (according to the schematics).

 

I'm afraid that due to numerous fixes, daughterboards etc. there is a whole bunch of cards by the same name which behave all differently...

 

BTW, I suggest to rename the command PDMA to BDMA (Block DMA).

I suppose this depends on what you currently mean by "crashing" and "WHTech SCSI card". 

 

Unmodified cards work with PDMA OFF, modified cards work with PDMA ON, and the only time that I have been informed of lockups (crashes?) is when the wrong mode is selected.  This sometimes happened with earlier versions of Geneve OS due to a detection error. 

 

I am not opposed to changing the PDMA command (or aliasing it) since in most cases, the OS detection routine should select the proper code based on the EPROM Version:  Version 1.5 == older "PDMA off" non-block mode and Version 1.6 == newer "PDMA ON" block mode.  Older EPROM versions should would default to "PDMA off".  All cards updated by @Swim  should would have the 1.6 EPROM installed.

 

For the record, I have tested PDMA ON with WHT SCSI cards revision F and G w/EPROM 1.6; PDMA Off with WHT SCSI Revision E and F w/EPROM 1.5.   I can do some further testing in December, maybe others in the crowd can fill in the gaps.  Schematics and memories are fickle things - one or both could be wrong, until proved otherwise. 

 

[+mizapf]

I meant lockup; it is caught in an endless loop because the expected bus status does not show up.

 

So the WHTech card, as I emulated it, only works with PDMA OFF. Saving seems to work as well, so I can actually consider pushing the changes to the master server. Unless someone insists on getting the block mode working.

 

BTW, to make things worse or at least a bit more difficult, the 53C80 emulation in MAME is not complete. In particular, there is no READY output which is needed for the block DMA mode. I'm not sure whether it is worth trying to add that now.

[+mizapf]

OK, just tested: MYS, POWER, and SCUZZY are working with MAME's SCSI emulation. Also, the TI console is still OK with the SCSI emulation.

Looks well enough to work with it. I'll investigate more into Block DMA for a later release ... For now, this is a WHTech SCSI card with 1.5 EPROM, not modified (but it can handle word transfer).

 

Edit: I uploaded the 1.5 EPROM to the WHTech FTP as ti99_whtscsi.zip. The ti99_complete.zip has also been updated. I have to do some minor clean-up work before I commit the card emulation in MAME to the master server but it seems likely to make it into the next release (0.238).