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 6
  • 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 2

Share this post


Link to post
Share on other sites

Is anything fundamental of the F18A preventing you from switching to another sprite attribute table half way down the screen and thereby getting another 32 sprites?

The reason I'm asking is that my code is only working in emulation. I'm calling this GPU code at each Vsync:

*      Set sprite attribute table 1
       li   r0,(spratb/>80)*256        ; Value for VR5 (table 1)
       movb r0,@>6005                  ; Set VR5
       movb @top_sprites,@>6033        ; Set max sprites (VR51)
*      Set hsync trigger
       movb @>6032,r0                  ; Get contens of VR50
       ori  r0,>4000                   ; Set hsync bit
       movb r0,@>6032                  ; Set VR50
*      Return
gpu_program_5:
       idle
*      Hsync handler
       cb   @>7000,@split_y            ; Check scanline no
       jl   gpu_program_5              ; Wait if not reached
*      Set sprite attribute table 1
       li   r0,(sprat2/>80)*256        ; Value for VR5 (table 2)
       movb r0,@>6005                  ; Set VR5
       movb @bottom_sprites,@>6033     ; Set max sprites (VR51)
*      Clear hsync trigger
       movb @>6032,r0                  ; Get contens of VR50
       andi r0,>bfff                   ; Clear hsync bit
       movb r0,@>6032                  ; Set VR50
*      Return
       idle
split_y:
       byte >88

The sprite attribute tables have been sorted so that sprites at the top of the screen are in the first one and sprites at the bottom of the screen are in the second one. This is done by other code that also sets @top_sprites and @bottom_sprites.

The result on a real F18A is that only sprites in the bottom half are visible.

 

Maybe it has something to do with how I start the GPU?

*      Set the GPU PC which also triggers it
       li   r0,gpurun/256+>3600
       bl   @vwtr
       li   r0,gpurun%256+>3700
       bl   @vwtr

Is it not correct that this also starts the GPU?

Share this post


Link to post
Share on other sites

Found it. Just needed to change the test for the scanline from jl to jne. On the real F18A it looks like I get higher numbered scanlines after the vertical interrupt - even in 30 row mode. I need to change the emulator to reflect that.

  • Like 3

Share this post


Link to post
Share on other sites

Yeah, IIRC it counts up to 255 and holds there until the frame resets.

 

Share this post


Link to post
Share on other sites
On 3/20/2021 at 5:11 AM, Asmusr said:

Is anything fundamental of the F18A preventing you from switching to another sprite attribute table half way down the screen and thereby getting another 32 sprites?

The sprites are pre-processed on the line before where they appear, so that is the only limitation to changing the sprite table.  But you already found your bug, so this is just additional information.

 

On 3/20/2021 at 5:50 AM, Asmusr said:

On the real F18A it looks like I get higher numbered scanlines after the vertical interrupt - even in 30 row mode.

The vertical interrupt happens at the end of the "visible area", i.e. around line 192 (this is in accordance to the 9918A datasheet).  There are 525 lines in the VGA frame, which divided by 2 is 262.5.  So once the real scan-line / 2 is > 255, it clamps at 255 until the new frame (about 7 virtual 2x lines and 14 VGA lines).  The counter does not clamp sooner because 30-row mode needs the additional line counts.  Those line counts *are* accurate, they are just counting the blanking area.

  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)

I've got a question

I've set my VR registers as such

TurboForth >04 >70 >03 >E8 >01 >06 >00 >F4 >88 >00 >00 >00 >94 >10 >00
BUT it's for my assembly program NOT forth, but I grabbed this because I'm not seeing anything that sets text only.
 
I'm only wanting text 80 mode and I got that working by using the above setting, however as my text information was displayed correctly but after running through a KSCAN routine that had been working fine prior to adding the F18A i lose my text mode and get pushed into 32 col graphics, or graphics 1 mode.
Any thoughts as to what is going on?
 
Thank you.
Edited by GDMike

Share this post


Link to post
Share on other sites
Posted (edited)
14 hours ago, GDMike said:

I've got a question

I've set my VR registers as such

 

A few things:

  1. Not only does VR01 need to be >F0 (not >70), but you need to be sure you write that byte to >83D4 before you write it to VR01. With >70, you are telling the VDP it has only 4 KiB of VRAM instead of 16 KiB (>F0).
  2. You need to write VR08 – VR14 before you write VR00 – VR07, just in case you do not have an 80-column-capable VDP.
  3. Not sure it matters, but I think I would set VR12 the same as VR07. (I think it matters for the EVPC card).
  4. It does not matter for Text or Text80 modes, but you have VR06 (Sprite Descriptor Table) set to >00 for SDT at >0000 (same as screen location). I usually set that to >01 for SDT at >0800, the default for Graphics mode.

Not sure any of these , except possibly #1, are your problem, but thought you would like to know.

 

...lee

Edited by Lee Stewart
CLARIFICATION
  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)
13 hours ago, Lee Stewart said:

Not sure any of these , except possibly #1, are your problem, but thought you would like to know.

 

On second thought, it probably is #1 above. If you do not set >83D4 to the value you want for VR01, KSCAN will set VR01 to whatever E/A cartridge startup put in >83D4, which is probably the value for Graphics mode.

 

...lee

Edited by Lee Stewart
CLARIFICATION
  • Like 1

Share this post


Link to post
Share on other sites

I'm also using SAMs banks for address >3000. Does F-18A do anything with that base address?

Thank you again. I see your point in post#692. Good stuff

Share this post


Link to post
Share on other sites
1 minute ago, GDMike said:

I'm also using SAMs banks for address >3000. Does F-18A do anything with that base address?

Thank you again. I see your point in post#692. Good stuff

 

Your SAMS window at >3000 is RAM. The F18A deals only with VRAM, I believe.

 

...lee

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
13 hours ago, Lee Stewart said:

 

Your SAMS window at >3000 is RAM. The F18A deals only with VRAM, I believe.

 

...lee

I had remd' out a SAMs routine as I was ruling things out and so that explains my Sam's error I was getting.

I didn't know about reversing the VR register use, and makes sense, now. That vr1 is >F0. I was just comparing to TF numbers that I had seen from another post.

With all the changes you suggested, by golly, I'm up and working again!!

Everything worked like a charm on my new program, FOXIT.

My Sam's addressing and my setting to text mode!

Fyi, this new program I'm working on is a DB it's going to be text mode. 

I still need to learn how to switch back to graphics mode for colors one day though.

My PC is down and I don't have access to the VR register spreadsheet, but I do have a new graphics card coming in Thursday and I'll take a look at that spreadsheet that Matt I believe put together way back when.

Thank you Lee, awesome memory you got!. Sometimes I wonder about you being part computer.

 

 

Edited by GDMike
  • Like 1
  • Haha 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...