Porting paged TI games to the Geneve

[+dhe]

Does v91 above point to the fixed version?

[+InsaneMultitasker]

On 7/9/2022 at 5:29 PM, dhe said:

Does v91 above point to the fixed version?

No. I was finishing some changes to Flying Shark tonight, which is now also working with the 'rom simulation' approach.  Scratchpad memory usage aside, the Geneve keyscan works well enough and doesn't seem to inhibit frame rate or gameplay.  I have a few ideas to pursue and a bit more cleanup before I release any updates.

[+InsaneMultitasker]

I played around with conditional assembly.   If Geneve9640==0, the /4a routines are assembled, otherwise the Geneve routines are assembled.  Banking now uses a BLWP routine with a register representing the corresponding >60xx bank address. Bank offsets, where necessary, are applied based on a conditional delta.  So far, the approach seems to be fine.  I'll try the same with Flying Shark later this week and refine as needed.  

 

; [0] 4a standard code;  [<>0] use 9640 code

Geneve9640 equ 1

      .ifne Geneve9640
Geneve_bank_delta   equ >2000   ;adjust from >6000 to >4000 bank location
      .else
Geneve_bank_delta   equ 0
      .endif

 

; /// Example of conditional banking

; /// Not all game routines use R2, so there are vectors for R0,R1,etc.

      .ifne Geneve9640
         blwp @genevemap_r2    ;set bank, r2
      .else
         seto *r2
      .endif

[+Ksarul]

17 hours ago, InsaneMultitasker said:

I played around with conditional assembly.   If Geneve9640==0, the /4a routines are assembled, otherwise the Geneve routines are assembled.  Banking now uses a BLWP routine with a register representing the corresponding >60xx bank address. Bank offsets, where necessary, are applied based on a conditional delta.  So far, the approach seems to be fine.  I'll try the same with Flying Shark later this week and refine as needed.  

 

; [0] 4a standard code;  [<>0] use 9640 code

Geneve9640 equ 1

      .ifne Geneve9640
Geneve_bank_delta   equ >2000   ;adjust from >6000 to >4000 bank location
      .else
Geneve_bank_delta   equ 0
      .endif

 

; /// Example of conditional banking

; /// Not all game routines use R2, so there are vectors for R0,R1,etc.

      .ifne Geneve9640
         blwp @genevemap_r2    ;set bank, r2
      .else
         seto *r2
      .endif

A variation of this routine might be useful to port things to the Tomy Tutor/Pyuuta using the >8000 space for their cartridges. . .

[+InsaneMultitasker]

On 7/9/2022 at 5:29 PM, dhe said:

Does v91 above point to the fixed version?

Updated PINBALL 99 loader, with keyboard and joystick support. Speech is reportedly working as well.  Files are in TIFILES format.

I applied the scoring fix that Rasmus released a few days ago.  My changes are limited to banking, keyboard, and memory support.

 

The loader currently requires both the original ROM and the updated program files.

 

PINBALL99 for Geneve loader v95.zip

 

Documentation text.

Pinball 99 Loader v0.95 for the Geneve 9640

       Based on EXEC 2.7 (C)Barry Boone, Updated by Insane Multitasker

       Pinball is written by Rasmus Moustgaard

         PINROM256         v1.01 ROM from the /4A distribution; unchanged
         PINLOAD           Geneve native OS program; file loader
         PINBALL,M,N,O     Pinball program, modified for Geneve use

       Place all files in the same path.  Load as follows:

       PINLOAD PINBALL

       The file PINROM256 will automatically load from the same path as PINLOAD

       ROM banking simulation is achieved by using >4000-5FFF and Geneve memory
       map support. Keyboard routine is modified to support Geneve keyscan.

       Future release may simplify the loader requirements to eliminate the
       separate program image load.

History:
7-16-2022 Updates for keyboard support
7-6-2022  Initial release

[+InsaneMultitasker]

Flying Shark with loader v0.93.

 

This ROM loader requires 512K free space for the ROM and 64K for the program.  Memory expansion, such as the 384K mod, Memex, Myarc 504K, etc. is required.  

 

The ROM image is 2048 sectors, therefore, a 720K disk/disk image, ramdisk formatted to 800K, or "hard drive" device (SCSI, IDE, HFDC, TIPI, RamHD) is required.

 

FLYING SHARK for Geneve loader v93.zip

[+InsaneMultitasker]

On 7/12/2022 at 3:09 PM, Ksarul said:

A variation of this routine might be useful to port things to the Tomy Tutor/Pyuuta using the >8000 space for their cartridges. . .

A variation of the mapping certainly could work.  I opted to use the TI environment for the above two games but it would have been nearly as simple to change the video/sound ports and implement a stand-alone keyboard routine.  I'm not yet sure whether I prefer the /4a method or the native /9640 mode method (used for Tilda) to simulate the ROM.  I might try the latter for a different game after a few other efforts are further along.  The one challenge right now is that keyboard control can only output one key at a time, which doesn't simulate holding one or more keys like you can on the TI.  In Flying Shark, my keyboard routine is limited - you cannot move diagonally or fire while moving, like you can with the joystick. I simply ran out of time to finish emulating output that mimics the CRU-based keyboard.

[Asmusr]

@InsaneMultitasker are you going to make the source code available? 

[+InsaneMultitasker]

Just now, Asmusr said:

@InsaneMultitasker are you going to make the source code available? 

Yes, that is my intent once I figure out the cart header/loader approach.  I would prefer to eliminate the extra set of program files.

 

Also, I originally added my code directly into your source files.  I have since moved most of the code into its own support file(s) for the Geneve, with conditional assembly statements for the COPY statements and alternate code.  To me, this seemed like a cleaner way to do things and may provide a template for others.

[+arcadeshopper]

btw Pinball seems to have stopped working in MDOS 7.43  I was running 7.3 worked fine.. updated.. now im getting in mame;

[:maincpu] Undefined opcode 0d0c at logical address 000a, will trigger MID
 

Greg

[+hloberg]

here the fixed LOGO 2 for the Geneve. haven't tested extensively but what I have tested it seems to work. just run GPL or MYGPL on the LOGO2 file(s) on the LOGO2 .dsk.

LOGO 2 fixed for the Geneve.zip

[+InsaneMultitasker]

On 2/17/2024 at 2:35 PM, arcadeshopper said:

btw Pinball seems to have stopped working in MDOS 7.43  I was running 7.3 worked fine.. updated.. now im getting in mame;

[:maincpu] Undefined opcode 0d0c at logical address 000a, will trigger MID
 

Greg

What about 7.42. 

[+InsaneMultitasker]

On 2/17/2024 at 2:35 PM, arcadeshopper said:

btw Pinball seems to have stopped working in MDOS 7.43  I was running 7.3 worked fine.. updated.. now im getting in mame;

[:maincpu] Undefined opcode 0d0c at logical address 000a, will trigger MID
 

Greg

Also try 7.40 in addition to 7.42.  Will help to isolate. It seems we ran into something like this once before.  Just to confirm you are using the latest version I released in the pinball topic?

[+mizapf]

I also tried it, and I'm hitting this MID in 7.42 as well, shortly after starting. I could isolate it as happening after the first BL @>000E.

 

By the way, another future GeneveOS request from me is to have an easy way to redirect the MID vector (i.e. not by editing the GeneveOS files). Something like "SETMID (xx:)xxxx" (with or without bank setting). If there is some space left.

[+mizapf]

Here are the last steps before the MID

 

[+InsaneMultitasker]

6 minutes ago, mizapf said:

Here are the last steps before the MID

The first screenshot looks like a joystick CRU test, I would think it is unrelated to the code in the latter 3 screenshots which are steps in executing a peripheral powerup.  Notice that R11 contains >F0F0 in the last screenshot.  R11 should contain an address for the DSR powerup routine either on the card (rompage) or in the Geneve OS DSR.  The problem is almost certainly in the pinball loader, either a mistake in the powerup or somehow not conforming to the fixes made within the Geneve OS DSR.  Actually, this feels way too familiar as if I fixed this already:  I suspect the pinball cartridge is paged into 0x4000 in place of Geneve OS page 0x07 or peripheral bus 0xBA.  I will try the game in a short while, over my lunch time.

[+InsaneMultitasker]

@mizapf the code you identified is from the Pinball loader's interrupt handler (not the powerup as I mistakenly thought at first glance).

 

It seems that on July 19 of 2023, I fixed the loader;s interrupt handler.   It was not mapping the DSR page into 0x4000 before jumping into the master DSR's interrupt routine, so the R11 value is from whatever 8k cartridge page is banked into memory at that time. This is why the problem sounded familiar to me. What I don't understand is why this fix wasn't posted, since I had releasted 1.5 a few days earlier. Maybe that is when I started working on the new keyboard scan routine. I can't make sense of my files and my lunch is over, so I will look again this week.   (I do not know why the same loader works in 7.30, chance success perhaps.)

[+InsaneMultitasker]

Ok, I found the compiled PINLOAD v.96 19-July-2023.  I replaced the version from the 1.5 ZIP with this file and the game started properly under MDOS 7.42.  @arcadeshopper and @mizapf hopefully this resolves the issue.

 

PINLOAD

[+InsaneMultitasker]

Deja vu.  Here is the topic from July 2023 where we identified the same problem.   The RS232 card was generating an interrupt which then exposed the bug that I fixed in the handler. Perhaps most people are not using an RS232 in MAME. I do not know if we determined why the interrupt occurs and if there is a difference in timing between a real RS232 and an emulated RS232?  Or perhaps the real geneve just ignores the problem and is able to continue on its way, depending on the phase of the moon or number of sunspots at the time.

 

 

[+mizapf]

Ah yes, I do remember, sorry for putting up that topic again. I'll replace the PINLOAD on my images.

[+InsaneMultitasker]

1 minute ago, mizapf said:

Ah yes, I do remember, sorry for putting up that topic again. I'll replace the PINLOAD on my images.

No apology is necessary;  I never published the updated PINLOAD.  I was almost certainly distracted by the new keyboard routines that I was writing and testing and then, well, life got in the way as often is the case with the hobby. 

 

 

[+arcadeshopper]

That was it!  Thanks

 

 

[+9640News]

And just by chance, I had deleted the RS232 card from my MAME use ...........

 

Beery

[+InsaneMultitasker]

Looking for some XT keyboard expertise... 

 

I gnawed on my Flying Shark/Ghostbusters XT to 4A CRU keyboard translation routines tonight.  In Flying Shark, if I press LEFT&DOWN or UP&RIGHT for diagonal movement, then press spacebar to fire, the game freezes.  Releasing an arrow key resumes the game.  I had thought the bug was in my code so tonight I wrote a short program to output the raw make/break codes received from the keyboard. 

 

It turns out that in many cases, a third key triggers a single code of 0xFF which is slowly repeated until one of the first two keys is released, at which time the respective break codes are received.  Code >FF is not valid but since no other code is received, my routine spun around in a loop. The 3-key limitation occurs with other key combinations as well. 

 

Is it valid to assume the XT keyboard processor limits certain combinations of keys based on the keyboard matrix?

 

The game no longer freezes; I process and throw away the 0xFF.  If this is a keyboard hardware limitation, then I'll move forward with a second alternate key for 'fire' for keyboard users.  (TAB and CTRL both work as a third key for all diagonals).