Jump to content
IGNORED

Supernotes


GDMike

Recommended Posts

In order to do a save file or a load file, do we want the user to have to plug in the supercart?

The program started off supporting the SC then this version started to vary away from it to where it's only needed to read data from a supercart,(SNE) earlier version.

But we can go in that direction??

The reason I brought it up was that I may need buffer space to push my pages out of high ram??

Edited by GDMike
Link to comment
Share on other sites

I could make it optional. Hmm maybe I already did..I can't remember..

I'll look at it later AFTER my disk access for saving and loading is done. I really want to focus on that.

Hope your dizziness had gone away too.

Thx for your help on this project.

I wanna get done with it. But i don't want to take shortcuts.

I have found source code, I think it was http://www.stuartconner.me.uk/ti/ti.htm

anyway it explains how to read write to tipi. That's also my goal.

Edited by GDMike
  • Like 1
Link to comment
Share on other sites

DEF  DISKIO
       REF  VMBW,DSRLNK
PAB    DATA >0600,>0000,0,840,>000B
       TEXT 'DSK1.PAGEXX'
PABADR EQU  >3000
DISKIO MOV  R11,R10
       LI   R0,PABADR
       LI   R1,PAB
       LI   R2,21
       BLWP @VMBW
       LI   R2,PABADR+9
       MOV  R2,@>8356
       CLR  @>837C
       BLWP @DSRLNK
       DATA 8
       MOV  R10,R11
       RT
       END

Dang, how am I not seeing this stuff.

Again, I apologize. I have a partial excuse

But I won't talk about it here .

Sorry people for missing this.

Work with me. Thx

Link to comment
Share on other sites

Assembly times: 2:50 on the classic99

At regular speed and 3:40 on TI PEB using ramdisk for both source load and save file.

34 seconds at high speed classic99.

Sometimes when using classic99 at high speed assembling I get erroneous error and it didn't matter the assembler program I was using, but sometimes it's fine too. 

 

IMG_20200604_164806960_HDR.jpg

Edited by GDMike
Link to comment
Share on other sites

28 minutes ago, GDMike said:


 

Dang, how am I not seeing this stuff.

Again, I apologize. I have a partial excuse

But I won't talk about it here .

Sorry people for missing this.

Work with me. Thx

Been there myself, and will be there more often in the future...…….

 

Beery

  • Thanks 1
Link to comment
Share on other sites

So getting back to configuring the PAB.

What are the rules in doing this as in, do i need my pages to be at a particular size or in a particular area in ram?

I'm looking to answer- what preliminary steps am I wanting to have in place prior or as a requirement for setting this up?

I have 17 pages,(so far), of data. And it's located in high RAM and I think, I'll have to go back and check, but their maybe some in low ram too.

I see Eric has a layout of the PAB, "fields," byte definitions as I was looking at that.

Byte 0: OPCODE
Byte 1: Flagbyte/status
        MSB 7 6 5 4 3 2 1 0 LSB
            | | | | | | | |
            | | | | | | | +— Filetype: 0=sequential, 1=relative record type
            | | | | | +-+--- Mode of operation(2): 00=Update, 01=Output, 10=Input, 11=Append
            | | | | +——— Datatype: 0=Display, 1=Internal
            | | | +————Record type: 0=Fixed length, 1=Variable length
            +-+-+—————————— Errorcode(3): 0 = no error
Bytes 2,3: Data buffer address
Byte 4: Logical record length: 
* Record length of fixed records or
* Max length of variable record length (see flag byte)
Byte 5: character count:
* Number of characters to be transferred for write opcode, or
* number of bytes actually read for a read opcode
Bytes 6, 7: Record number: 
* only required for relative record type file
* indicates the record number of the current I/O operation (0-32767)
* highest bit ignored
Byte 8: screen offset: 
* offset of the screen characters in respect to their normal ASCII value
Byte 9: Name length:
* Length of the file descriptor following the PAB
Byte 10+: File descriptor:
* device name and, if required, the filename and options.
* the length of this descriptor is given in 9.

Now I gotta figure out what this means. Lol

It'd be great if i can make it easier to understand.

I know I'll be doing my pages as text, which I understand DOES NOT mean it's DV80. But, in my case I want to make my pages compatible with other DV80 readers, so I'll be wanting my files read and saved as DV80.

My pages are in ram and are 840 bytes per page.

 

 

Edited by GDMike
  • Like 1
Link to comment
Share on other sites

18 hours ago, Stuart said:

Have a read of Chapter 9 of [http://www.hexbus.com/tibooks/misc/introduction-to-assembly-language-for-the-ti-home-computer.zip]. It explains file access quite well.

Ahhh...yes. chapter 9, I remember seeing this, like 100 years ago. 

If it's still a solid reference, as you suggest, which is why you pointed it out, I'll study it.

There are quite a few things that are going on at once to track which makes it hard for the beginner, like me. It's beautifully laid out here, which is great!

I'm looking for what isn't listed that I'm not aware of though. I didn't want to push it to vdp RAM, I was hoping to just have my data in high Mem where it is already and mov it from there.

Is that explained too? I'll have to see.

Maybe I could substitute some things here.

Of course I want the fastest way to transfer.

Thank you so much... the layout in the book looks simple enough, doesn't it.

 

 

 

Edited by GDMike
Link to comment
Share on other sites

56 minutes ago, GDMike said:

I'm looking for what isn't listed that I'm not aware of though. I didn't want to push it to vdp RAM, I was hoping to just have my data in high Mem where it is already and mov it from there.

You have to move your data to VDP RAM before you can save it. And you can only load data from disk into VDP RAM. 

  • Sad 1
Link to comment
Share on other sites

11 minutes ago, GDMike said:

So my next question is, since my file structure is DV80, do I just move enough data to cover the 80 bytes at a time?

If not, I'll have to Hunt for a 2k holding area.

This is a strange feeling  to move partial data...lol

You can move as much as you want or can fit into VDP ram, you would just need to change the pointer for the buffer address for each write call along with adjusting the length to write.

 

If you copy multiple records to VDP ram, you are going to have to either "store" the pointers/length as you move the data for each record, or re-read the source data you are moving to setup for each change in the PAB.

 

If I recall correctly, I think there is at least one, if not two disk controller cards (not TI) that allow writes from CPU to disk.  Still requires the PAB to be in VDP, but I think there is an additional flag that permits writes from CPU ram.  If you test for those cards, you may be able to "jump" over the CPU to VDP transfer routine to speed things up.

 

I found these details in the Myarc HFDC manual:

 

The HFDC supports two extensions to the standard PAB. The first extension is to support I/O to CPU RAM rather than VDP RAM. In other words, the data buffer points to a CPU RAM location rather than a VDP RAM location. In order to perform CPU I/O, merely set bit 1 (where bit 0 is the MSB and bit 7 the LSB) of the opcode byte. Everything else will remain the same. The second extension to the PAB is to support total CPU RAM use of PAB and data buffer. The DSR ROM will assume that the PAB is in CPU RAM when the MSB of >8354 is a "1". The configuration of the PAB in CPU RAM is a subset of the 9640's PAB. 

 

The above is at page 47 of the file at http://ftp.whtech.com/datasheets and manuals/Hardware/Myarc/MYARC HFDC Manual 2nd edition.pdf

 

Also, found this for the SCSI controller card with the file listed below of data that can be transferred directly to CPU bypassing VDP.

 

The above is at page 7 of the file at http://ftp.whtech.com/datasheets and manuals/Hardware/WHT/scsi/manuals/Preliminary SCSI Hardware Manual.PDF

 

I thought CorComp was the first to do this, however, I could not find any details of this in their manual.  Just know the TI controller card does not, and I think the TIPI uses all transfers to VDP.  Not sure about the HRD.

 

Anyways, if you test for the card and have a confirmation screen by the user perhaps in a config section, then you may have faster transfer speeds with at least some devices than others.

 

 

Beery

 

Edited by BeeryMiller
  • Thanks 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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