Jump to content

Recommended Posts

2 hours ago, Lee Stewart said:

 

The code I slightly modified is from MG’s The Smart Programmer, V2(2), July, 1986. Here is my transcription of it:

Thanks Lee, that is interesting. One silly question (I have only written the receiving end of a DSR, i.e. the actual DSR): the calling convention you mention is:

	BLWP @DSRLNK    
	DATA 8

I am curious about the use of the parameter 8. How is it used? If I have understood properly scratchpad location >8356 must be initialised with the PAB structure pointer (offset 9) in VDP memory. Sorry I haven't taken any time to dig into this.

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, Asmusr said:

If you want to speed things up you should look into how to avoid any VDP reads and how to avoid settings up the VDP write address more than once. 

Thanks. Yes I have the solution for this already: do all processing by the Cortex M4 on the cartridge and write the data to be written to VDP memory to a memory area in the cartridge memory, and then have a very simple routine in scratchpad memory for the TMS9900 to just loop though the data and write it to VDP. Then the whole thing will become VDP memory write bandwidth limited. Simple structures like: count, VDP destination address, count bytes of data.

 

My current scrolling routine already sets VDP address registers very seldom (that is the reason for the vertical strips).

 

But before I go there, I want to first play around with TMS9900 code without help by the Cortex M4 core since that is kind of cheating, although I will be more than happy to cheat once I get to that part of the project 😁

 

But I did do some benchmarking of my prototype scrolling code, comparing the same code on the some of the different systems I have:

  • TI-99/4A (8.3 seconds)
  • My "legacy" EP994A FPGA core (around 0.7s @ 100MHz) with 31 wait states but cache enabled.
  • My "new" Icy99 core on the ICE40HX (around 1.5s @ 25 MHz).

I could not run my EP994A FPGA core at full speed due to some stupid versioning reason, and I did not want to run again the synthesis. I did find a bug in my Icy99 core: on the ICE40HX platform the VDP memory is located in external SRAM. It is actually an UMA system (unified memory architecture - just one memory bus shared between CPU, VDP, and DMA from host). With the scrolling routine putting "a lot" of memory transfer load between the CPU and VDP,  the VDP screen refresh engine sometimes runs too slowly, which causes annoyingly a temporary loss of vertical sync, i.e. screen flashes. It is funny how the different projects reveal new issues. By keeping the code in the TMS9900 assembly it is actually a lot of fun to test drive it in all of these other systems.

Share this post


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

Thanks Lee, that is interesting. One silly question (I have only written the receiving end of a DSR, i.e. the actual DSR): the calling convention you mention is:

	BLWP @DSRLNK    
	DATA 8

I am curious about the use of the parameter 8. How is it used? If I have understood properly scratchpad location >8356 must be initialised with the PAB structure pointer (offset 9) in VDP memory. Sorry I haven't taken any time to dig into this.

 

The DSRLNK routine pops the data after its call to get from the caller whether s/he wants a high-level device service routine (8) for the device at the beginning of the file descriptor field in the PAB or a lower-level subprogram (10), whose name (often only a hex number) is passed in the PAB. When the DSRLNK returns, it will be to the address after “DATA 8” or “DATA 10”. For the diskette DSR, 8 is for level 3 DSRs, all of which use the PAB we all know and love with >8356 pointing to the name-length byte (byte 9) of the PAB in VRAM. Diskette DSR subprogram call 10 is for level 1 and 2 routines that usually use a 2-byte PAB in VRAM, which holds a counted string containing the name of the subprogram and the namelength byte for which is pointed to by >8356 and a transfer block at FAC or FAC+2 and an additional information block pointed to by the transfer block, both of which are in CRAM.

 

...lee

 

[EDITs: Corrections per @jedimatt42’s post below and, hopefully, some clarifications are in the color of this note.]

Edited by Lee Stewart
ADDITIONAL INFO and CORRECTIONS
  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

That's funny I've written my TIPI ROM with DSRs long before I ever wrote a DSRLNK or a call to one in assembly... LOL... 

 

To be strict, it is the DSRLNK routine in question that read that word at the return address to determine which NameLink list to search in the ROM headers.. 

 

8 bytes into the ROM header is where the device service routine list for each ROM begins, and 10 bytes into the ROM header is where the subroutine ( CALL FILES, level2 management routines, etc ) list begins. 

 

Conveniently TI spec'ed both lists with the same structure, so one name searching routine with an offset is all that is needed. Many ( most? ) DSRLNK routines floating around expect this, but not all. 

 

 

  • Like 3

Share this post


Link to post
Share on other sites
2 hours ago, jedimatt42 said:

That's funny I've written my TIPI ROM with DSRs long before I ever wrote a DSRLNK or a call to one in assembly... LOL... 

 

To be strict, it is the DSRLNK routine in question that read that word at the return address to determine which NameLink list to search in the ROM headers.. 

 

8 bytes into the ROM header is where the device service routine list for each ROM begins, and 10 bytes into the ROM header is where the subroutine ( CALL FILES, level2 management routines, etc ) list begins. 

 

Conveniently TI spec'ed both lists with the same structure, so one name searching routine with an offset is all that is needed. Many ( most? ) DSRLNK routines floating around expect this, but not all. 

Thanks, now this makes sense! I did the same, wrote a DSR before starting to think how they get called. The 99/4A would not be the 99/4A, unless the PABs and file buffers were in VDP RAM too :) That was my first thought when working on the DSR. Of course for an unexpanded computer that's nearly all RAM one's got.

  • Like 3

Share this post


Link to post
Share on other sites

Hi,

  Speccery, when we last meet here, he started another branch regarding the DSRLNK.

  I was wondering if you have had time to work on things like Pascal Emulator, maybe console grom over-ride or just getting what you have ready for people to try out?

Thank,

Dan

 

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...