What would it take...

Opry99er · April 23, 2015

...for a PBox card to override the standard startup of the TI and run an entirely different "system?"

The Geneve did this... I think PCode did as well...

If, say, one wanted to have fbForth start up with no cartridge installed, could it be made to run on a card without allowing access to the TI startup screen?

How difficult would it be to create this alternate environment... With potentially an entirely new boot-up process and even alternate start menu? Could TurboForth and fbForth be made to populate the same board and turn the TI into a Forth machine, with a custom start screen?

It is just a curiosity at this point, but putting these languages on a PBox card and having an alternate reality for my TI is something I've been sort of thinking about.

Could the actual cart EPROMs be used to populate the board OR would alternate versions need to be created?

Just wonky thoughts... Any ideas?

Omega-TI · April 23, 2015

Without a cartridge in the slot? Sounds a little like a P-GRAM card to me.

Opry99er · April 23, 2015

Except they would be ROMs... No revision capabilities, just cart ROMs on a board, bypassing startup and with a custom startup screen.

Tursi · April 23, 2015

The Geneve didn't have a TI attached, so that's kind of cheating.

But all the GRAM cards did that by overriding the console GROMs (basically just driving the lines harder than the real GROMs could). That's all it takes - once you get control with a GROM or DSR startup you can do whatever you like. The pCode card did this as well.

I'm still toying with my alternate OS in the background, but, I don't expect to release anything this year due to work.

Stuart · April 23, 2015

Except they would be ROMs... No revision capabilities, just cart ROMs on a board, bypassing startup and with a custom startup screen.

I think you need a DSR on the card with a power-up routine that takes control and doesn't return back to the console software. The card would need to be on a CRU address higher than all the other cards so that their power-up routines (if any) get run first.

Opry99er · April 23, 2015

So, would the ROMs used for the cartridges be usable here? If so, I imagine the board layout would be a fairly simple one...

3 EPROMs, socketed, one with fbForth, one with TurboForth, and one containing the "OS" menu and startup protocols?

Edited April 23, 2015 by Opry99er

Opry99er · April 23, 2015

I need to get my SID card out and have a looksee... It is my only caseless card, and IIRC, it was a nice, simple layout.

I also need to study up on DSRs.

+Ksarul · April 23, 2015

Maybe you could start with a protoboard, Owen. . . I think I still have one of those left that I was planning on using for testing (I need to order more of them to keep them available too). It already has the basic bus glue logic and power in place. . .Note that there would be a need to bank-switch the EPROMs if you planned to have access to the 32K--so your glue program would have to manage that, answering for the >6000 space (like the HSGPL and P-GRAM do).

Edited April 23, 2015 by Ksarul

Opry99er · April 24, 2015

Thanks Jim.

I an tinkering around in my head right now, but do not yet possess the knowledge required to produce the results I want. Ive been reading some stuff on DSRLNK and a couple things from Thierry's page (much of which I will have questions about if I ever decide to actually work on this).

The EPROMs that go in the carts... Would those be usable on this board? Have one of each and another containing my DSR, startup protocols and menu? (Total of 3 EPROMs)

Again... Nowhere near ready to do this, but it has been an educational day reading up on how some of this stuff is accomplished.

Opry99er · April 24, 2015

Ive spent the last 3 hours on Thierry's Tech pages. Wow... is the only word I can find.

Opry99er · April 25, 2015

Does this look like a valid PAB?

My only concern is PAB byte 1... There are several bits that must be set to describe the file type, mode of operation, and data type... I am not sure how to go about that one...

FORPAB  BYTE 2,0         /"read opcode" (bytes 0,1)
        DATA VDPBUF      /address of PAB in RAM (bytes 2,3)
        BYTE 0,10        /number of bytes to read (bytes 4,5)
        BYTE 0,0         /no relative record type (bytes 6,7)
        BYTE 0           /not accessing CS1 or CS2, so "zero" (byte 
        BYTE 9           /length of file descriptor (byte 9)
        TEXT '99FORTH-A' /file descriptor (bytes 10+)
ENDPAB  EVEN

Edited April 25, 2015 by Opry99er

Tursi · April 25, 2015

Almost... the file descriptor needs to be a full device path, so like "DSK1.99FORTH-A"

You need to set the file mode in the OPEN opcode, and it just needs to match the type of file that you are opening (assuming it's for read). (And you need to OPEN before you can READ). When you're building up that byte, set >10 if it's a VARIABLE file (if not set, it's FIXED), and set >08 if it's INTERNAL (else it is DISPLAY), and set >01 if it's RELATIVE (else it's sequential). These have the same meanings as in BASIC and you just OR (or add) them together. You also set the mode of open (UPDATE, OUTPUT, INPUT or APPEND) using two bits, UPDATE is >00, OUTPUT is >02, INPUT is >04 and APPEND if >06. Finally, you should also set the record length in byte 4 (the count only goes in byte 5 - no more than 255 bytes at a time). So for instance, to open a D/V 80 file for INPUT:

OPEN #1:"DSK1.README",INPUT,DISPLAY,VARIABLE 80

the PAB would be:

PAB
 BYTE >00,>14     * OPEN, INPUT, DISPLAY, VARIABLE
 DATA >0000        * buffer not needed for OPEN
 BYTE 80,0           * max record length of 80, no read or write
 DATA >0000        * E/A has a mistake - you need the record number for /fixed/ files, but not variable. Relative versus sequential has no bearing (by my testing)
 BYTE 0                * no screen offset for CSx
 BYTE 11              * length of file descriptor
 TEXT 'DSK1.README'

For READ, you would update the access mode (byte 0) and the character count (byte 5) and the VDP buffer (bytes 2-3), and leave the rest the same. You can check for errors in byte 1 as well, the 3 most significant bits are reserved for the error code (that's why it's 0-7 in TI BASIC).

Tursi · April 25, 2015

Actually, if you want to see examples, you can actually type in BASIC commands like above, and use the Classic99 debugger to see what the PAB created looks like. I did a simple example like the above, if you then look at the debug, you will see a line like so:

DSR opcode >0 on PAB >37D1, filename DSK1.README

That tells you where in VDP memory the PAB was stored (>37D1). Now, the catch is that address points to the period in the filename (the DSR has to work backwards from there), you can just page back a bit to look at the beginning. Knowing that it's DSK1, you know that the beginning of the PAB is always going to be 14 bytes earlier than that. (So in this case, >37C3):

37C3: 00 F4 00 00 50 00 00 00 ....P...
37CB: 60 0B 44 53 4B 31 2E 52 `.DSK1.R
37D3: 45 41 44 4D 45 AA 3F FF EADME.?.

So, 00 - command OPEN

F4 - break it into bits: 1111 0100:

- 0-2 = Error Code = 111 = 7 = File Error (makes sense, the file does not exist in my test)

- 3 = Record Type = 1 = Variable length

- 4 = DataType = 0 = Display

- 5,6 = Mode = 10 = Input

- 7 = File Type = Relative

00,00 = Data buffer - >0000 (not used in OPEN)

50 = Record length - >50 = 80 in decimal

00 = character count = 0 (not used in OPEN)

00,00 = Record Number = 0 (always set to zero by OPEN)

60 = screen offset = >60 = 96 decimal - I did this from TI BASIC, and that is the correct screen offset

0B = name length = >0B = 11 decimal - DSK1.README is 11 characters

Opry99er · April 25, 2015

Wow, excellent. Thank you Tursi.

What if I am writing a PAB as part of a DSR for an as-yet non-existent PBox card?

Then I do not have a full pathname.

Opry99er · April 26, 2015

My head is hurting... LOL!!!

So, to give myself something simple with which to start, I decided to write a program to OPEN "DSK1.TEST" and read a record from the file. There is only one record in the file, and it is the following text:

"IT WORKS!"

DSK1.TEST is a FIXED record-length file.

Pages 303 and 304 of the EA manual have a semi-commented program that doesn't seem to make much sense to me. Lots of EQUates and moving around of pointers with very little commenting.

Luckily, I have Mark Wills and the Forum "Search" function at my command.

Hope he doesn't mind. This program was written to copy the RS232 ROM to DSK2. It is well-commented and (while similar in context and content to the EA Manual's version) is pretty dang easy to understand.

Now this is alot more than I need,it is a good place to get a reference for my little project. THANKS WILLSY!

    DEF START
    REF VMBR,VMBW,DSRLNK
 
SAVEOP  EQU 6           memory image save opcode
VDPPAB  EQU >1000       address of PAB in VDP
LEV3IO  EQU 8           code for standard level 3 disk io
PNTR    EQU >8356       address of name length in VDP pab must be written here
 
MYPAB   BYTE SAVEOP,0
        DATA VDPBUF
        BYTE 0,0
        DATA 8192
        BYTE 0
        BYTE 13
        TEXT 'DSK2.RS232ROM'
ENDPAB  EVEN
VDPBUF  EQU VDPPAB+$-MYPAB address of rom image in VDP (follows PAB)
 
* copy pab to vdp ram
START   LI R0,VDPPAB    vdp destination
        LI R1,MYPAB     source
        LI R2,ENDPAB-MYPAB  # bytes to transfer
        BLWP @VMBW      send PAB to VDP
 
* copy DSR ROM to VDP
        LI R12,>1300    cru address of card
        SBO 0           turn on DSR ROMS
 
        LI R0,VDPBUF    we'll put DSR here
        LI R1,>4000     address of DSR ROM
        LI R2,8192      8K of ROM
        BLWP @VMBW      send the dsr to VDP
 
        SBZ 0           switch off DSR roms
 
* now execute a SAVE command using DSRLNK
        LI R0,VDPPAB+9  address of name byte in VDP pab
        MOV R0,@PNTR    required for DSRLNK
        BLWP @DSRLNK
        DATA LEV3IO     standard level 3 disk io
 
        RT              return to editor assembler environment
 
        END

Opry99er · April 26, 2015

The EA manual program does a really nice job of showing how to update modes during the program (for OPEN, switching to READ, etc)

READ    BYTE   >02        
CLOSE   BYTE   >01
 
 
.
.
.
 
        MOVB   @READ,R1
        LI     R0,PAB
        BLWP   @VSBW    /Change I/O op-code to READ

And here's the E/A manual's PAB

DATA    >0004,PABBUF,>5000,>0000,>0009
TEXT    'DSK1.DATA'

That blob block of DATA is the PAB. Nice and compact, but it doesn't explain what any of it does in the source. (I know, newbs suck)

I'm learning... this stuff is pretty in depth (for me, anyway)

Edited April 26, 2015 by Opry99er

Tursi · April 26, 2015

Wow, excellent. Thank you Tursi.

What if I am writing a PAB as part of a DSR for an as-yet non-existent PBox card?

Then I do not have a full pathname.

Looks like you're doing well so far.

You should still use a name of some sort to get things lining up correctly -- in your first example PAB, the /device/ that the console will search for is called '99FORTH-A', which is longer than the maximum of 7 characters that the standard DSRLNKs use, so will fail without even searching for the card. Since it won't exist anyway, it's just to be in the habit.

Opry99er · April 26, 2015

Thanks again.

I want to say this is fun, but....

Maybe when I can get my little program working, display the text onscreen, etc.... Maybe THEN it will not seem like yanking teeth out of my face.

Gracias good sir.

Willsy · April 26, 2015

Luckily, I have Mark Wills and the Forum "Search" function at my command.

THANKS WILLSY!

Know what? I have no recollection of writing that! Must have been a quick 5 minute write-and-forget type gig! Looking at your own code and saying "Hey that's neat! " is somewhat disconcerting! :-)

+OLD CS1 · April 26, 2015

Know what? I have no recollection of writing that! Must have been a quick 5 minute write-and-forget type gig! Looking at your own code and saying "Hey that's neat! " is somewhat disconcerting! :-)

Gotta be better than looking at old code and going, "What the HELL was I thinking?!"

Tursi · April 26, 2015

File stuff on the TI is a bit confusing at first glance. Hell, I only got my own assembly code for record-based files working properly for the first time a few weeks ago.

(Edit: But I /meant/ to say, once you've put it together the first time, it's not so bad anymore )

Edited April 26, 2015 by Tursi

+Lee Stewart · April 27, 2015

The console’s cassette DSR is the only one that needs >60 in the Screen Offset byte (byte # of the PAB and the only one where the description “Screen Offset” has any meaning. It is extremely confusing that the EA manual says “This is used only by the cassette interface ...” because it is used by the disk DSR’s STATUS operation (opcode = 9) to report a file’s status on disk. The EA manual’s statement should have been qualified to say that the byte is only used as input by the cassette interface. Interestingly, the cassette DSR does not use byte #8 to report file status. Rather, it uses byte #6 (not otherwise used by the cassette interface) in order to preserve the >60 in byte #8.

...lee

Opry99er · April 27, 2015

That is quite confusing... Reading these pages in the E/A manual has made me dislike the E/A manual. LOL!

Gary from OPA · April 27, 2015

Screen offset is needed if DSR going to output characters to the screen, which the Cassette DSR does, I don't know of any other DSR which did, the reason for screen offset is because the actual A-Z letters are not really A-Z ascii wise for when Cassette DSR is being called, so a value has to be added for right one to appear.

As for taking over the system it is very possible, many products did in their own way, Horizon ramdisk was one with their power-up loading of MENU. -- I modded my CF7+ DSR to take over the system, and Corcomp did also with one of their own DSR's.

As for PBOX card containing GROM to take over system that is possible also, but it needs one wire soldered inside the console, and normal 9800 grom access does not appear outside, the reason why the p-code had its groms running in the DSR space instead.

But if PBOX card just going to contain ROM, bank switched in or even >6000 space (that you can override easy from PE-BOX, the Horizon does that with the RAMBO mod, placing banks of 8K in >6000 space), the DSR just needs a good power-up routine, and if I was designing a new code I would have it decode at >1B00 CRU that way you could make use of the XOP opcodes and undefinded tables of unknown code that the console rom branchs to if found.