Jump to content
matthew180

F18A programming, info, and resources

Recommended Posts

1 minute ago, ralphb said:

Thanks for getting back.  I figured as much about the cable, since it's not really straight, but gets twisted inside the TI quite a bit.

Most of the failures I have seen have been breaks of the wire where it is soldered into the DB-15 connector.  You can slide the plastic shell down the ribbon cable to expose the wires and check visually.  I have not seen the ribbon cable itself break due to bending or anything, it is braided wire and pretty flexible.  The pigtail is available from http://www.pccables.com part number 07129, "VGA HD15F to IDC16".  I know it is inconvenient, but that is the only source of this kind of cable I could find, and one of the reasons the MK2 will use its own cable and header.

  • Like 1

Share this post


Link to post
Share on other sites
8 minutes ago, ralphb said:

The 4x image was quite funny, since the TI 99 just crashed, and I didn't make use of any F18A features at all ...

I have seen this happen occasionally with devices that take control of the console at power-on, for example my CF7+ sometimes causes problems at power on when it hijacks the power-on sequence to put its text on the master title screen.  I'm not sure of the dynamics going on, since the F18A powers-up in a locked mode.  But, if it gets unlocked, then all bets are off.

Share this post


Link to post
Share on other sites
23 minutes ago, matthew180 said:

So, it was pretty short-sighted of me when I made the VRAM over 4K private to the GPU.  That will probably change, even with the original F18A firmware, to make what is "private" GPU VRAM accessible via the VDP Address Register, but only when the F18A is unlocked (for compatibility reasons).  I also want to try to squeeze a little more VRAM out of the original F18A by not being so casual with the Block-RAM I used for line buffers (it might provide an additional 2K of VRAM, but no promises).

Does "private to the GPU" mean that it's not possible to use it for drawing the screen? I was hoping a quick fix would be possible. In js99er a 6K sprite table at >3000 would have the 3rd bit plane at >4000 because that RAM follows the 16K VDP RAM, but maybe the F18A is not organized internally like that? 

Edited by Asmusr

Share this post


Link to post
Share on other sites

"private to the GPU" just means, like a lot of the design, I should have thought about it a little more, thought about future expansion of the memory space, and / or had a few more discussions on the forum about it.  It is totally possible to have a little more VRAM for the original F18A, but now I have to figure out how to do it without breaking everything (existing F18A software, mostly) all to hell, where to put the new required address bit(s) (ideally the same place the 9938 added them), when to enable the extension to retain 9918A compatibility, and where / how to move the GPU memory-mapped devices (VRAM regs, the DMA, etc.) out of the VRAM address space.

Share this post


Link to post
Share on other sites
8 minutes ago, matthew180 said:

"private to the GPU" just means, like a lot of the design, I should have thought about it a little more, thought about future expansion of the memory space, and / or had a few more discussions on the forum about it.  It is totally possible to have a little more VRAM for the original F18A, but now I have to figure out how to do it without breaking everything (existing F18A software, mostly) all to hell, where to put the new required address bit(s) (ideally the same place the 9938 added them), when to enable the extension to retain 9918A compatibility, and where / how to move the GPU memory-mapped devices (VRAM regs, the DMA, etc.) out of the VRAM address space.

I understand that, but I'm not asking for more RAM or extra registers or more bits. I'm just asking that the sprite pattern address doesn't wrap around at >4000 but proceeds into the 2K private GPU RAM. That would make it possible to use all the F18A features together.

Edited by Asmusr

Share this post


Link to post
Share on other sites

My request would not break any existing software or create any backwards incompatibility because no F18A software has been created that expects the address to wrap around, and on the 9918A it's not possible to place the sprite pattern table so that it would wrap around. This is the VDP layout I'm hoping to be able to achieve:

nametb equ	>0000				       ; Name table base
namet0 equ	>0000				       ; Name table page 0 (64 bytes free)
namet1 equ	>0400				       ; Name table page 1 (64 bytes free)
namet2 equ	>0800				       ; Name table page 2 (64 bytes free)
namet3 equ	>0C00				       ; Name table page 3 (64 bytes free)
ptrntb equ	>1000				       ; Pattern table base
ptrnt0 equ	>1000				       ; Pattern table plane 0
ptrnt1 equ	>1800				       ; Pattern table plane 1
ptrnt2 equ	>2000				       ; Pattern table plane 2
nam2tb equ      >2800                                  ; Name table 2 base (64 bytes free)
tilatb equ	>2c00				       ; Tile attribute table
spratb equ	>2d00				       ; Sprite attribute table (640 bytes free)
sprptb equ	>3000				       ; Sprite pattern table base
sprpt0 equ	>3000				       ; Sprite pattern table plane 0
sprpt1 equ	>3800				       ; Sprite pattern table plane 1
sprpt2 equ	>4000				       ; Sprite pattern table plane 2

 

Share this post


Link to post
Share on other sites

Like the 9918A, the F18A's internal address register is truly 14-bits, and the wrap-around is just a natural function of the hardware.  To let the VADR (VDP Address Register) continue to address memory over >3FFF would require an extra address bit (not a huge deal, maybe), but then that address bit should probably also be made accessible via VREG (VDP Register) to accommodate the future changes that will come with the MK2 (and to make them as compatible as possible).  The MK2 will need 5 more address bits, the MK1 will have 1 extra address bit (and memory over 18K or 20K will probably wrap).

 

I can't remember where the 9938 put the extra address bits, but it was in a low VREG IIRC (I will look it up later).

 

This *might* be a change I can introduce early, but I will want to have at least worked out all the design details first, of how it will ultimately work for compatibility with the MK1 and MK2, and where the GPU memory-mapped devices will go.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, matthew180 said:

This *might* be a change I can introduce early, but I will want to have at least worked out all the design details first, of how it will ultimately work for compatibility with the MK1 and MK2, and where the GPU memory-mapped devices will go.

Great. Here's a teaser of my project. The map consists of 700 tiles that are loaded on the fly as needed. I have already added a few sprites like the gas tanks. I'm not sure if it will be possible to turn this into a game and maintain the original graphics - even with 64 sprite patterns - but with only 32 patterns this is not going to proceed beyond the demo stage.

 

  • Like 4
  • Thanks 2

Share this post


Link to post
Share on other sites

That is pretty cool.  It makes me wonder what the graphics subsystem capabilities for Zaxxon are.  One thing the arcade games typically have over home computers is, more ROM in the CPU memory map, and a graphics subsystem that can read directly from those ROMs.  What they typically do not have (talking classic arcade game era here) are relocatable video tables and redefinable patterns.  The 9918A's ability to relocate the various tables in VRAM actually adds to a lot of complexity, and I always wondered what the actual benefits are?

  • Like 1

Share this post


Link to post
Share on other sites
18 hours ago, matthew180 said:

The 9918A's ability to relocate the various tables in VRAM actually adds to a lot of complexity, and I always wondered what the actual benefits are?

I don't think any of my smooth scrolling games would be possible without it. But that's probably not what they thought about when they designed the 9918A.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...