New MAME release

[+mizapf]

Weird. Really, works for me: http://www.mizapf.eu/files/mame/genevesay.webm

 

Please test this minimal configuration:

 

mame ti99_4a -cart exbasic -ioport peb -ioport:peb:slot3 speech

 

Next, try it with the Geneve, with minimum config:

 

mame geneve -peb:slot2 speech -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 Bootdisk1.HD -flop1 dsdd1.dsk

 

[globeron]

40 minutes ago, mizapf said:

Weird. Really, works for me: http://www.mizapf.eu/files/mame/genevesay.webm

 

Please test this minimal configuration:

 

mame ti99_4a -cart exbasic -ioport peb -ioport:peb:slot3 speech

 

Next, try it with the Geneve, with minimum config:

 

mame geneve -peb:slot2 speech -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 Bootdisk1.HD -flop1 dsdd1.dsk

 

 

It also works for me.   MAME v0.256,   non-GenMod 1.00      MDOS 7.30  and ABASIC 4.04DDI

 

(mame.exe geneve -bios 1.00 -peb:slot5 speech -peb:slot6 tirs232 -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic -hard1 disks\genhd01.hd %*)

 

 

 

 

[+arcadeshopper]

Works with less things connected.. 

./mame geneve -colorbus busmouse -peb:slot2 speech -peb:slot8 hfdc -peb:slot6 tipi -conn rpi.tipipz2 -window -oslog -bios 2.00
 

adding this

 

./mame geneve -colorbus busmouse -peb:slot2 speech -peb:slot4 memex -peb:slot8 hfdc -peb:slot6 tipi -conn rpi.tipipz2 -window -oslog -bios 2.00
 

Gets me uhohs 

[+mizapf]

I found that this line produces "HELLO":

 

./mame geneve -window -bios 2.00 -peb:slot4 memex -peb:slot5 speech -peb:slot6 tipi -peb:slot8 ddcc1 -conn rpi.tipi

 

while this one produces "UHOH" (5 times):

 

./mame geneve -window -bios 2.00 -peb:slot4 memex -peb:slot2 speech -peb:slot6 tipi -peb:slot8 ddcc1 -conn rpi.tipi

 

See the difference?

 

Which is a bit unsettling and requires more thoughts. Not a trivial bug.

[+InsaneMultitasker]

Is the Memex incorrectly blocking (or unblocking) one or more pages, based on slot precedence?  

[+mizapf]

The MEMEX overrides the accesses of the speech card. The PEB emulation starts with slot 2 and steps through each slot until 8, so if there are concurrent accesses, the last one wins.

 

The line that produces HELLO also means that values from the MEMEX are spoilt, while the opposite occurs for the other ordering.

 

As far as I remember, and also implied by the dip settings, only the pages BA and multiples are blocked, not BC.

[+9640News]

46 minutes ago, mizapf said:

The MEMEX overrides the accesses of the speech card. The PEB emulation starts with slot 2 and steps through each slot until 8, so if there are concurrent accesses, the last one wins.

 

The line that produces HELLO also means that values from the MEMEX are spoilt, while the opposite occurs for the other ordering.

 

As far as I remember, and also implied by the dip settings, only the pages BA and multiples are blocked, not BC.

I wonder if there is an issue with the AMA/AMB/AMC decoding.  When I turned it off previously, loading ABASIC resulted in what I would call "noises" coming from my speakers.

 

It has been awhile from my memory, but pages >3C, >7C and >BC would respond to speech if the page was not fully decoded on a GenMOD system.  On a non-GenMOD system, page >BC would respond.

 

Later versions of MDOS blocked page >BC from the list of available memory pages for a task.

[+mizapf]

It's not only the problem for GeneveOS to avoid the page BC, but when we directly write to 9400 or read from 9000 in the PEB, this is an access to memory that is also available on the MEMEX. The description of the MEMEX does not say that this bank is blocked like the BA bank.

 

... which would lead me to suspect that using speech and MEMEX in the same box is probably not recommended.

 

Timings in the real system may trigger a different behaviour, but it is at least hard to predict.

[+InsaneMultitasker]

The below routine is how ABASIC sets up prior to executing a speech call.  By comparison in GPL mode, page >03 is mapped and page >BC is never mapped.  Does this imply for /4a mode, the gate array always propagates the speech ports to/from the external bus?  I -think- the /4a mode bit (1EF4) inhibits external bus access for video, gram, and sound, but I've never confirmed this.  The Memex DIP switch can block out >BA but doesn't block >BC, to my knowledge. I would guess that speech access 'corrupts' Memex page >BC, at the speech port addresses.  Maybe @FarmerPotato has poked at some of this with Geneve2020.

 

TI994  LIMI 0
       MOVB @MAP98,@PAGE8S    SAVE THE CURRENT PAGES
       MOVB @MAP9C,@PAGECS
       MOVB @CBHBC,@MAP98     NOW MAP IN THE >BC PAGE TO >8000
       MOVB @CBH03,@MAP9C     AND >03 TO >C000 PAGE
       LI   R12,>1EF4         NOW GO INTO 4A MODE
       SBZ  0
       LI   R12,>1EFE
       SBZ  0
       RT

 

 

 

 

[+9640News]

Well, I moved the speech card to a slot # higher than the MEMEX card.  Now, "HELLO" works in ABASIC.

 

So, my next test was to answer a question asked of me regarding MAME.  I am finding MAME does not like PINBALL for the Geneve with Speech.  It may be the speech emulation in MAME was pushed beyond the limits.

 

Beery

[+mizapf]

10 hours ago, 9640News said:

Well, I moved the speech card to a slot # higher than the MEMEX card.  Now, "HELLO" works in ABASIC.

You have to be aware that either one may corrupt the other one's memory access. If the speech synthesizer is in a higher slot, you may have proper speech, but in turn the accesses to memory locations 9000 and 9400 may be corrupted.

 

10 hours ago, 9640News said:

So, my next test was to answer a question asked of me regarding MAME.  I am finding MAME does not like PINBALL for the Geneve with Speech.  It may be the speech emulation in MAME was pushed beyond the limits.

I am not aware of particular limitations of the speech emulation in MAME. I mean, that part is not from me, but it worked pretty well for all other applications.

I'd have to know what "does not like" means here. It's always possible we still have a glitch in the integration of the speech chip in the Geneve system.

 

Tim wanted to give it a try, as he told me.

[TheMole]

10 hours ago, 9640News said:

So, my next test was to answer a question asked of me regarding MAME.  I am finding MAME does not like PINBALL for the Geneve with Speech.  It may be the speech emulation in MAME was pushed beyond the limits.

Are you sure you're using the latest update of Pinball99 that @InsaneMultitasker put together? See his post from last Saturday here...

 

[+9640News]

2 hours ago, TheMole said:

Are you sure you're using the latest update of Pinball99 that @InsaneMultitasker put together? See his post from last Saturday here...

 

Yes, same version. 
 

3 hours ago, mizapf said:

You have to be aware that either one may corrupt the other one's memory access. If the speech synthesizer is in a higher slot, you may have proper speech, but in turn the accesses to memory locations 9000 and 9400 may be corrupted.

 

I am not aware of particular limitations of the speech emulation in MAME. I mean, that part is not from me, but it worked pretty well for all other applications.

I'd have to know what "does not like" means here. It's always possible we still have a glitch in the integration of the speech chip in the Geneve system.

 

Tim wanted to give it a try, as he told me.

Memory page BC is blocked from task mapping. I will double check I did not leave ama, amb, and amc in the off state in some of my testing. 

[+mizapf]

As I said, the problem is not with GeneveOS and its mapper. You can always attempt to write to address 9400 or read from 9000. The problem right now is that two devices in the PEB may feel accessed by that, so this is a physical issue. The memex blocks accesses to bank BA from its memory to avoid this, but to my knowledge, it does not do that for bank BC where the 9000/9400 addresses are.

 

The bad thing is that the speech synthesizer has no CRU bit for turning off and on. It is slower than other memory, so this may save the real system from these collisions, but they may show up in MAME as you noted.

[+FarmerPotato]

@InsaneMultitasker
 

Sorry, no, I didn't investigate off-board accesses. 

I only designed Geneve2020 to recognize mode bits 1FEx plus fixed device addresses (8800 in GPL, F110 in MDOS, etc.) Memory-mapped devices can be forwarded onboard or off-board. Page BC is just ordinary RAM. 

 

So I might have a bug. Is page BC always sent external, even when not mapped at 8000?  The ABASIC code seems to imply it needs to be from 8000. 

 

Now I want to use that extender card you sent me, for verifying this. 

[+mizapf]

To my understanding, all pages B8-BF are sent external into the PEB. It makes sense to map BC to 8000 if it contains code (for the absolute addresses), otherwise you can map it anywhere.

 

I described it like this: https://www.ninerpedia.org/wiki/Geneve_physical_memory_map

and https://www.ninerpedia.org/wiki/Geneve_logical_memory_map

[+9640News]

Well, I cannot comment about the hardware emulation under MAME, just that on the real iron, Pinball works on the Geneve.

 

I do not know if anyone has tried running the 4A version under TI-99 emulation?  I do not follow the 4A emulation to know if all the necessary hardware has been emulated.

[+mizapf]

When I tried to run pinball (1.5) on the MAME Geneve I got an illegal instruction (MID). Is that what you mean?

[+mizapf]

@InsaneMultitaskerThis is the point where it happens; it's code from PINLOAD. I'm not sure what it tries to do here; R12 is set, but no CRU operation, could be.  But then it gets a word from 400c which is (see the memory dump) some arbitrary value (63d7) which is not even suitable for the MOV at 1a54 because it is an odd number. R11 is then filled with F0F0 because this is what you find at 63d8. The words at that location look a bit like character definitions; definitely not a jump table. I'm not even sure we are at the proper location here or if the error occured earlier. The only thing I know is that on BL *R11 (really? this will overwrite the current R11) we land at F0F0 which contains a 0000, which then triggers MID.

[+InsaneMultitasker]

3 hours ago, mizapf said:

@InsaneMultitaskerThis is the point where it happens; it's code from PINLOAD. I'm not sure what it tries to do here; R12 is set, but no CRU operation, could be.  But then it gets a word from 400c which is (see the memory dump) some arbitrary value (63d7) which is not even suitable for the MOV at 1a54 because it is an odd number. R11 is then filled with F0F0 because this is what you find at 63d8. The words at that location look a bit like character definitions; definitely not a jump table. I'm not even sure we are at the proper location here or if the error occured earlier. The only thing I know is that on BL *R11 (really? this will overwrite the current R11) we land at F0F0 which contains a 0000, which then triggers MID

Nice sleuthing. PINLOAD is built upon EXEC code. You are looking at the external master DSR interrupt handler for the emulated /4A environment. During gameplay, memory from 0x4000-0x5fff is used to simulate the ROM cart.  This means the master DSR page >07 is no longer visible at the expected address, which in turn means the interrupt linkage is invalid.  Naughty.

 

Are you able to determine which device caused the interrupt condition?  Can the speech card or speech interface generate an interrupt? If so, the master DSR would not know how to clear it or service it.  I suppose the right approach is to page in the master DSR and allow it to service the interrupt, but I don't know if this is a valid interrupt situation.  Gameplay shouldnt generate external bus interrupts.  Or maybe I am missing some application here.

 

NCSS   LWPI >82E0            Check ext interrupt
       CLR  R12
       TB   >01
       JEQ  NOINT
*
* 7..28.94  INTERRUPT HANDLER...
*

DOINT1000
       LI   R12,>1000         MDOS Master DSR Interrupt
       MOV  @>400C,R11        this is simple...
       JEQ  NOINT
       MOV  @2(R11),R11
       JEQ  NOINT
       BL   *R11              do it!
       NOP
NOINT  LWPI >83E0             restore GPLWS
       B    *R12              return to level 1 interrupt routine

 

[+dhe]

@mizapf  -- "Ninermame ... all you ever wanted to know about the TI-99 emulations in MAME"

 

 In my defense, I looked here first.

 

 InsaneMultitasker has convinced me of the power of pushing bytes to the RS232 port for debugging.

 

 I've seen very little on the topic of MAME and serial ports, can you explain in a "MAME RS232 for Dummies" way - how I setup an RS232 and where the bytes go to under MAME?

[+mizapf]

I should say that I don't get too far when starting Pinball. The last thing I see is "Loading program...", a graphics mode switch with something flashing up, then black screen, the speech synthesizer says something like "ho...", and the sound generator starts with a faint noise.

 

The way I usually track down such an issue is that I activate the log to see if there is something like a crash (like here, MID triggered), and then I activate the logging of memory locations in the source code of the 9995 (LOG_EXEC) and recompile MAME. By that I can see where the execution was when the error occurred. Then I use the debugger of MAME (-debug) to set a breakpoint near that location.

[+mizapf]

Oops, it's working now.

 

Guess how? - I left away the RS232 card.

 

Ah, and speech is working too. The only glitch left is that it says "Welcome to Pinball on the TI-99/4A computer". Should sound more like "Geneve" .

[+InsaneMultitasker]

20 minutes ago, mizapf said:

Oops, it's working now.

 

Guess how? - I left away the RS232 card.

 

Ah, and speech is working too. The only glitch left is that it says "Welcome to Pinball on the TI-99/4A computer". Should sound more like "Geneve" .

My real Geneve has an RS232 and it does not exhibit this issue. Interesting. 

[+mizapf]

The RS232 is a component (unlike the speech synthesizer) which can actually raise interrupts. It also depends on the card; is it an original TI RS232?

 

It remains to find out why the interrupt is raised at all. But that may be quite easy to find out - in an emulation. This may also be a bug, I don't know yet but I'll find out.

 

This shows again why I always recommend to drop the cards and whistles and bells as far as possible when things don't run well in the emulation.