Give your 4A a new Brain!

[+Vorticon]

 

hehe, I will look at it. No promises as I don't actually know why it doesn't work today! (But in fairness, I know a lot more today than I did last time I looked at it.) Still, I do kind of question the value since it's not widely distributed in real life. (Of course, if the value is "because I want to do it", I never question that value ).

 

It may not be widely available in real hardware, but if it is under emulation then I think it will encourage some to support it from a software standpoint. It's a pretty powerful development environment with a full implementation of Pascal. My thinking is, if you build it, they will come All it will take to raise awareness of the P-Code system is a nice program such as a game. I am happy to loan you my P-Code card if it will help you debug the emulation issue.

[Tursi]

Very cool! From a practical standpoint though, how do you plan on incorporating this inside the console? Or do you just plan on keeping the microcontroller board external?

 

The GROMs inside the console are socketted. There will be a small PCB that you plug into one (maybe two for stability) of the GROM sockets. I won't likely be using this microcontroller, or at least not this package, I'll be choosing a physically smaller one. No wires needed - just pull the three GROMs and plug in the board.

 

I shouldn't need the pCode card, at least not anytime soon. Of course, I can't promise to look at pCode anytime soon either. :/

[+Vorticon]

One can only hope

[kl99]

Hi Tursi!

 

I love your project and seeing it already working is wonderful!

 

As far as I know there were several bugs found in the original GROM0 and GROM1 for which there exists fixed GROMs:

As far as I know Winfried Winkler, Heiner Martin and SNUG do earn most credits for those fixes

http://home.arcor.de/system-ninety-nine-user-group/index_e.htm

 

Please correct me if I am wrong.

 

As far as I understand the german manual from this SNUG peripheral card which lets you put the GROM0 and GROM1 outside of the console into the PEB [http://home.arcor.de/system-ninety-nine-user-group/hsgpl/hsgpl-mb.pdf]:

 

Bug N°1 - Review Modul Library:

 

Let me try to translate from the german manual:

 

The OS reads the GROM3 at >9800, address space goes from G>6000 to G>7FFF. The GROM3 gets compared with the GROM which is referenced at >9804. In case it's identical, the search gets canceled and the Message REVIEW MODUL LIBRARY will be surpressed. On a standard console this will always be the case because of the not fully decoded area of GROM (>98xx, >9Cxx).

 

In case a difference is found, you will get "REVIEW MODUL LIBRARY" as your last item on the first selection screen. If you select this item, you will get to the next Screen. The next page (site?) gets searched for modul-names and the system builds up a new selection list based on the search results. If no modul is found, "Review Modul Library" will be the only item. There are 16 pages you can page through. This paging can be continued until a module is selected. And now we come to the error in the original OS of the TI:

If the OS encouters a difference on the first comparison of GROM3, it by mistake reads out the GROM0 at >9804 as well. This means that on page 1 (>9804) you must have at least a GROM0. That's why the HSGPL (=SNUG card) always comes with 2 pages at least, and the Gram Part do come with two pages at least (>9800 and >9804). On the other pages you don't have to have anything. If however a module is on any other page, you got have at least a GROM0 on the same page.

 

Furthermore you need a GROM3 with correct header on every used page, otherwhise the page is not accessable and higher GROMs are not searched at all. To our luck almost all modules da use GROM3. Only a few game modules do come without one. The reason could be that the original plan was to release those games together with other games and were split up later. Examples are Zero-Zap (only GROM7), Hangman (only GROM5) and Connect Four (only GROM4). If those are on a GPL page, they are not found because of the missing GROM3. If you add any other game to them which uses only GROM3, you now get all module entries, although there could be an empty GROM between GROM5 and GROM7. It's important that on any used GPL-Page a valid GROM3 is found, otherwhise the whole GPL-Page is skipped.

 

Okay - as far as I understand the document, there is no bugfix for this yet?

 

 

Bug N°2 - Bug in TI Basic with the use of 80chars-cards:

 

 

The TI Basic which is on both GPL Pages is a version with corrected initial values for the V9938 VDP register.

 

This is important to enable the use of 80chars cards.

 

Original:

http://home.arcor.de/system-ninety-nine-user-group/hsgpl/grom0.bin

Fixed GROM0:

http://home.arcor.de/system-ninety-nine-user-group/hsgpl/grom0-80.bin

 

Bug N°X - Several bugfixes corrected in Extended Basic 3:

 

Extended Basic 3 was released in its original form and to my knowledge it fixes a lot of bugs in the original system from TI. My guess is that they were mostly bugs from XB though.

 

Other releated stuff:

 

Here you can find an interesting GROM0 designed by Winfried Winkler:

http://home.arcor.de/system-ninety-nine-user-group/hsgpl/grom0ww.bin

It allows you direct selection of GROM bases (whatever that is).

 

This is TI Basic with corrected 80chars-bug:

http://home.arcor.de/system-ninety-nine-user-group/hsgpl/tibasic.zip

 

This is an enhanced GROM0 which includes "EasyBug" but its meant for the SGCPU peripheral SNUG card:

http://home.arcor.de/system-ninety-nine-user-group/sgcpu/sgcpuupd.zip

[Tursi]

Thanks, KL99. I was aware of at least one of the bugs wrt 80 column cards, and I can fix that one myself without concern (TI oddly throws very invalid values into some of the VDP registers, and relies on the 9918 to mask it down to valid values. This caused me a lot of problems when I first wrote Classic99, before I knew about it ). You're right, though, this is a very good thing to get fixed now. Also was familiar with, though to less detail, the multi-base GROM scanning bug, as I found that when I implemented multiple GROM bases in Classic99.

 

(Multiple GROM Bases: the console allows you 40k of GROM space, accessed through the GROM "base" address of >9800. But it allows, in concept, another "base" to exist every 4 addresses. That is, at >9804, you are allowed to have /another/ 40k of GROM space. The console actually scans 16 bases, and when it finds more than one in use, that's when you see "Review Module Library" on the menu. There is room in the memory map for 256 bases! Selecting it lets you choose the next base. There's no hardware in the console to support it, though, all the hardware needs to live on the cartridge or PEB card. It's also a little slow to browse that way, I imagine Winfried's hack makes them all show on one list. Very nice, if rarely needed. I have one cart I made that would use it. )

 

Those are nice fixes though. And having all the GROM bases scan on one screen sounds very nice. The problem is - do Winfried, Heiner and SNUG allow others to distribute their code? I don't want to get into distributing code without permission. If you could point me to a document that says they are free to use, or point me towards who to contact without a lot of running around, then I'd be happy to see what they think. While I am wary about making too many changes to all the GROM0s, these are reasonable bugfixes. (I do wish they provided source for their patches so we could see more easily what they changed, though!!) Technically I could argue rights all day, but I'd rather just have a "yes, sure!", especially since I will need to further modify them to use them with my project.

 

The only one I can't do much with is XB, since I can only work with the console GROMs.

[John Doe]

Edited February 22, 2014 by Tony Knerr

[Tursi]

http://f1.grp.yahoofs.com/v1/4HmjTR3vVqKVGOBHKNfpB3_X8mot5G2zfNYzh_-2Bz3mWUCTYYDF0cjBMSWpHEKzTrxXF0jbX-TfddBlclK18A/TKGROM0-40col

 

http://f1.grp.yahoofs.com/v1/4HmjTdOHufCVGOBH6SZCeWuPRQVkjHJhgweL6V-myhGwejH6N17ZK4tWXAE7PO3zQEZWk1IZl8OyrwPrYeUi6A/TKGROM0-80col

 

http://f1.grp.yahoofs.com/v1/4HmjTf-3Q9OVGOBHyQukUfuvujeasn5cfKDUHqfP4bvys2XudnAnoDxePc5yizRkuI4veirup6eIyMILYIGG3w/Pgram%20Utilities.zip

 

Tursi,

 

You probably will be interested in the links above if you aren't already. The first two are for TKGROM0, 40 & 80 column versions.

After getting my SNUG system, I found the included Grom0 to be unreliable (the Winkler version?), so i did my own. The VDP fixes are in

place, and the 80 column version has an automatic screen saver. Grom base paging is done with the spacebar, and paging through the 16 Grom bases is very quick. Letters are used for menu selections to accomodate more than 9 choices, and are single-spaced. I removed the file headers from these two files as I just uploaded them and you probably don't need the headers.

 

The Pgram utilities disk is from the mid 90's. It includes GMENU, which allows presenting a scan of the Pgram's 4 grom bases on a single menu. By changing a single byte (I'd have to look for it), it can scan all 16 Grom bases, which is how I have it set up with my HSGPL card. Also included is a combined TI Writer and Editor Assembler package with no need for disk files, an editor similar to the

TI Writer editor is used. The other point of interest is a pack of three programs DISK UTILITIES, ARCHIVER, and MCOPY; all in one Grom

bank. It's probably a good idea to read the docs. The files on the .dsk image all have Gram Kracker/Pgram file headers on them.

 

I had to provide links for the files as found on the Yahoo TI Group site, as I wasn't able to upload them here.

 

Tony

 

That's great, Tony! I take it you are giving me permission to include these, including modifying them and distributing the modified versions in my project?

 

What is the functional difference between the 40 Column and 80 Column GROM0s, and are they /really/ 8k in size? I have to watch space, this is all loading into a single microcontroller. The single spacing and letters instead of numbers makes it pretty much the same as the 99/8 fake GROM I built, so I am thinking that I would like to include it as a separate GROM, and just backport your 80 column fixes to the other GROMs. (Hopefully I can identify them all, you didn't include source or notes either ).

 

The PGRAM disk probably I won't use. I'm writing my own shell, so I don't want to be upstaged by anyone else's in my own product. Besides, flash space is getting tight and the GRAM utilities won't do anything but get people's hopes up, hehe. I see on the disk that you released it all Public Domain, though, that's very cool.

 

Strange that you can't attach files to your messages. The links don't seem to work, but after some searching, I found them (third group I looked at, of course ).

[Tursi]

Hehe.. actually, it doesn't take long to see the difference between the 40 and 80 column versions... two bytes!

 

And I see you do use the memory about >1800, so all 8k is needed.

 

I also see a way to combine the two so that the 80 column version works correctly on the 9918A (and should still work on the 38/58), so I'm going to go ahead and do that patch. The problem comes down to the only MOVE statement that is changed, at startup.

 

MOVE >0008 to REG>00 FROM GROM@>1980 -- in the 40 column version

MOVE >0010 to REG>00 FROM GROM@>1980 -- in the 80 column version

 

I presume this is because the later VDP has 16 VDP registers (I could check, but too lazy). The problem is on the 9918, the last 8 registers in the 80-column version (8-15) get masked down to register 0-7 again, overwriting the valid values with invalid ones.

 

So, I'm going to jump ahead to some unused space, and replace the one MOVE with two MOVEs:

 

MOVE >0008 to REG>08 FROM GROM@>1988 -- load the 80 column registers

MOVE >0008 to REG>00 FROM GROM@>1980 -- load the 40 column registers

 

That should work. The only other difference in the two files is at >1877. Got this worked out now, too. This replaces the SCAN loop, in 40 column mode in scans normally, in 80 column mode it adds an extra test, and when the screen timeout reaches >2A00, it copies your screensaver to RAM and launches it.

 

I would also ask, what does "8 BIT RAM ACCESS ENABLED" mean? Is this tweaking any registers that won't be there? Remember that my GROM is only intended for the 99/4A.

Edited April 12, 2011 by Tursi

[John Doe]

Edited February 22, 2014 by Tony Knerr

[RXB]

...

I would also ask, what does "8 BIT RAM ACCESS ENABLED" mean? Is this tweaking any registers that won't be there? Remember that my GROM is only intended for the 99/4A.

 

"8 BIT RAM ACCESS ENABLED" sets a CRU bit in the SGCPU's DSR space. I seem to remember it's at >0F00, so it won't affect anything on a regular 4A. You could just eliminate that screen write, or fill the text with spaces. You'll probably want to change "SNUG" back to "HOME" also.

 

Tony

 

Tony was that for the mouse? I had the OPA SOB and 9958 and it had lines for that and something mentioned about RAM.

[John Doe]

Edited February 22, 2014 by Tony Knerr

[+InsaneMultitasker]

Interesting. I wonder if these or other CRU accesses explain why some of the 80 column programs I recently 'discovered' (on a TI Club ErrorFree disk from the 1998 Chicago Faire) won't fire up on the Geneve. Another project for a rainy day.

[Tursi]

Tony, I actually went through and hand-disassembled all the changes you made in your GROM there... I then went through, hacked, slashed, tweaked, and then decided to roll the concepts that I wanted to keep into my simulated 99/8 GROM instead. So the net effect is that I didn't keep yours or kl99's suggested ROMs, but rather rolled my own.

 

I wanted to see if you could give it a test on your 9938/9958 machine, just to make sure I got the VDP fix right (should be though!). In addition, I coded all GROM bases on one selection screen (because I really liked that idea), as well as the 99/8 font. This GROM does not include the MPD Configuration or Set Speed, though (which means that TI BASIC will show up as '@', where my config is supposed to go, but this does not harm anything.)

 

Here's a screenshot showing a reasonably loaded selection screen:

 

 

In that screenshot, MPD Config, TI BASIC, and Set Speed are at GROM base >9800, then each entry from MILLIKEN through to BLACKJACK is at a subsequence GROM base (>9804, >9808, etc). Finally, the last three entries are all CPU ROM.

 

The part of that I found most interesting, since I didn't expect it, was how it threw the order off to include all GROM bases. The console builds the list first by scanning ROMs, then each GROM base in order, top to bottom, storing the entries on a stack. When it displays, it dumps the stack backwards, so all the later GROM bases appeared /above/ TI BASIC. I tried a number of tricks to work around that, but the scan system didn't like them. Ultimately I implemented a bubble sort in GPL to fix the stack after the scan. Also, it checks for a maximum of 16 entries now. More than that corrupts the scratchpad RAM and crashes anyway (I'm not 100% certain 16 is okay, but I think I caught all the cases...)

 

When running without my MPD, you won't get MPD CONFIG or SET SPEED, that's normal. Those are auto-magic links added by my MPU.

 

The attached zip contains the GROM, and a text file with all the changes I made to the standard 99/4A GROM to get there.

 

Fake998GROM0.zip

[John Doe]

Edited February 22, 2014 by Tony Knerr

[Tursi]

Thanks for testing, Tony!

[Tursi]

I did quite a lot of work on this over the last two days (after a couple days break), and finally tonight completed "CALL DIR", which gives a disk directory from any loaded version of BASIC. It was more difficult than I expected, but it did finally come out, and I've tested on the real thing against both the CF7 and my real TI disk controller (happily, it worked). This is something I always wanted back in the day, now it will finally be there.

 

(I just thought to try it with XB.. and it doesn't work correctly there. It seems to parse the 'CALL' differently, and it looks like return to XB is different than return to BASIC. Guess I'm not done after all...)

 

There are now only 66 bytes left in my little "patch" GROM, which is a 2k fixed block, it's full of mostly hand-assembled and tested GPL. hehe, a lot of work! I need to pick up one of the assemblers now that we have good tutorials.

[John Doe]

Edited February 22, 2014 by Tony Knerr

[Tursi]

The return to the XB GPL interpreter is >06 >00 >12 >00.

That's what I see TI used and it always has worked for me.

 

Hmm.. that's the same as TI BASIC then... the behaviour is actually quite strange. The first call fails, and it seems to be failing correctly and returning properly. If I run it again, it actually works. But any XB program in memory is corrupted after the first call, and the token parsing buffer both moves and changes behaviour.

 

Not sure if I can explain it well enough yet, I have only spent about 10 minutes investigating, but..

 

I'm using the tip from Thierry's page to avoid tons of parsing by taking the argument as part of the name, so it works like:

 

CALL DIR.DSK1

 

In TI BASIC, I get a pointer to the string at >832C. It seems to usually be at VDP >0322, and is like so:

 

0322: 08 44 49 52 2E 44 53 4B 31 (length byte - DIR.DSK1

 

In Extended BASIC, the FIRST time I call it, the pointer is higher in memory, and it is parsed differently:

 

0822: 03 44 49 52 C8 01 2E 44 53 4B 31 (length byte - 3) DIR (C8 01 2E) DSK1

 

I don't know what the C8 01 2E sequence is, but my code assumes you just typed "CALL DIR", and returns an error.

 

Okay, I could cope with that and work it out. The part that baffles me is that if I immediately CALL DIR.DSK1 again, it comes up exactly like the TI BASIC version, buffer address and all. However, any XB program in memory is hosed.

 

(I am calling a TI BASIC error return.. maybe that's causing the changes, cause nothing in my code should be that I can see...? Maybe I'll try without that.)

 

Anyway, not so much a call for help yet, so don't do any digging. Let me spend some time on it first. But if you KNOW some tips offhand, I'll take 'em.

[Tursi]

I had a looksee and a little test, and I think I understand what's going on now.

 

The mysterious bytes are tokens. C8 is the token for "unquoted string", 01 is the length of the string, and 2E is the string ('.'). Following that, without additional token, is the rest of my string, ended by a zero byte.

 

The strange behaviour I saw was actually quite amusing. I call the 'print error' routine at G@>001C when I want to error out. I didn't pay attention to how it returns to BASIC - it jumps right back into the TI BASIC interpreter. Which means that after an error, my XB session was now running TI BASIC. No wonder it behaved differently the second time!

 

So I need to solve these things to work with XB as well. Hopefully other versions of XB didn't change this mechanism too much:

 

1) Detect and reparse the name string for XB. I need to count up the length manually now. That will be tough in the space I have available, though detection is easy, at least.

2) Implement my own error code so that I can return properly

 

I'm not sure how I will fit these things, but at least I know what to fit. In the meantime, I do have a question... why does my CALL work at all in XB? It's in GROM 0, but I thought the CALL syntax was supposed to be different? I'm not knocking it if it works, mind you.

[RXB]

I had a looksee and a little test, and I think I understand what's going on now.

 

The mysterious bytes are tokens. C8 is the token for "unquoted string", 01 is the length of the string, and 2E is the string ('.'). Following that, without additional token, is the rest of my string, ended by a zero byte.

 

The strange behaviour I saw was actually quite amusing. I call the 'print error' routine at G@>001C when I want to error out. I didn't pay attention to how it returns to BASIC - it jumps right back into the TI BASIC interpreter. Which means that after an error, my XB session was now running TI BASIC. No wonder it behaved differently the second time!

 

So I need to solve these things to work with XB as well. Hopefully other versions of XB didn't change this mechanism too much:

 

1) Detect and reparse the name string for XB. I need to count up the length manually now. That will be tough in the space I have available, though detection is easy, at least.

2) Implement my own error code so that I can return properly

 

I'm not sure how I will fit these things, but at least I know what to fit. In the meantime, I do have a question... why does my CALL work at all in XB? It's in GROM 0, but I thought the CALL syntax was supposed to be different? I'm not knocking it if it works, mind you.

 

Hope this helps a little. From the original XB source code and RXB are the same here.

 

<0370> 00C8 UNQSTZ EQU >C8 UNQUOTED STRING

<0371> 00C8 NUMZ EQU >C8 ALSO NUMERICAL STRING

<0372> 00C8 NUMCOZ EQU >C8 ALSO UNQUOTED STRING

 

So >C8 can be one of these three in the token stream.

[Tursi]

I got back to this one today, and finished it. I had a few issues to overcome.

 

First, I knew what I wanted, but because I hand-assembled the original code and filled in empty blocks where I could, it jumped around and a lot of the empty space was scattered. The only way to add more code was to consolidate it, remove the jumping around, etc. But in order to do that, I'd have to relocate everything, so finally I decided it was time to try an assembler.

 

I ended up on the RAG GPL Assembler, but if you've looked at my source, it should be no surprise that it wouldn't build. I learned GPL largely from years of studying TI Intern, and the syntax in that book is quite different. I reorganized my code, un-patched the patches (moving the code inline to save jumps), and of course, it didn't build.

 

Once I finally saw the syntax I needed, I wasn't too happy. The operand order was reversed and the MOVE instruction lost all context. At best, I figured that converting all my code by hand was going to be error-prone, so I ultimately went ahead and wrote a program to convert my GPL source code into RAG-compatible source. It took care of standardizing syntax, fixing the order of operands, and even truncating labels to six characters. So that worked.

 

Next I needed a way to do something with the object file. I like to do as much as I can on the PC side, just for speed and flexibility, so ultimately I went to a tool I wrote some years ago for cartridges, and added some hacky compressed object file support. Once I overcame the many issues with that idea, I was able to take the TI object file and output a binary result file. Then I just had to patch the binary into my output file, and bang! We were in business.

 

With some experimentation, I observed that the way TI BASIC and Extended BASIC tokenized the input string was actually the same if I did it the way you were supposed to, that is, CALL DIR("DSK1"), so ultimately I went with that. (Well, I don't test for the close parenthesis, since it isn't intended to run in a program, I didn't care ) With that in place, it worked on both BASIC and XB. I was also able to add my own error output code, since calling the one in TI BASIC wasn't safe (just a generic '* DIR FAILED'), and finally, because of the numerous ways you can be called from a running program, a test to reject calls when a program is running. (Although, with my own error handler, the program will keep running after the error is emitted ). But hopefully that'll be enough. (Interestingly, a running Extended BASIC program gets SUBPROGRAM NOT FOUND, rather than even trying! Good enough for me!)

 

So now that I have actual source code, I figured I'd post my CALL DIR here in case anyone else wants it. It takes about 512 bytes of GPL code, and you could relocate it anywhere. In the zip, calldir.txt is my commented source (also pasted below), and calldir_xlated.txt is the version converted by my tool, and can be compiled by RAGGASM.

 

... although now that I've done all the work zipping and attaching and pasting... it occurs to me that it won't directly work for anyone as it stands... I blindly steal 512 bytes of VDP memory for my buffers, plus I use another external block of RAM for text translation. Those could both be worked around by properly allocating blocks from the system, I suppose, I get away with it because I can restore the original data after. Well.... curiousity, maybe?

 

 

calldir.zip

 

 

* I give up! Time to move to an assembler.
* but I dislike the syntax, so I wrote a conversion tool for RAG asm
* code by Tursi

AORG >1D00

* before anything else, make sure we are not running. >8344 is zero in
* immediate mode, 01 for BASIC running, and FF for XB running. It's
* just not tested in a running program so not safe.
CZ @>8344
BR G@ERROR

* First, map the RAM bank into GROM 2, so we can back up a chunk of VDP space for our
* PAB and data buffer.
MOVE >0001 TO G@>1F12 FROM G@SRAMPAGE	* map in SRAM
MOVE >0200 TO G@>5E00 FROM VDP@>0D00	* copy 200 bytes out of VDP program space for our PAB and buffer

MOVE >000C TO VDP@>0D00 FROM G@PAB		* copy in PAB
MOVE >00F5 TO VDP@>0D0B FROM VDP@>0D0A	* repeat the periods to the end of the page

* CALL DIR("DSK1") works the same in BASIC and XB, so we can use that.
* we do this manually, we don't support running BASIC from GROM. 
DADD @>832C,>0004						* skip the length and DIR (only one possible name!)
DCEQ VDP*>832C,>B7C7					* must be open parenthesis followed by literal string
BR G@ERROR								* if not true, throw an error
DINCT @>832C							* skip those two tokens, now at the length byte
DCLR @>8300								* prepare count
ST @>8301,VDP*>832C						* get count
DINC @>832C								* skip the count byte

MOVE @>8300 TO VDP@>0D0A FROM VDP*>832C * copy the name from VDP
ST VDP@>0D09,@>8301						* copy the length too, now we're ready for the open call
INC VDP@>0D09							* increment the length to include the period (already stored)

OPEN				
DST @>8356,>0D09						* set pointer to PAB
CALL G@>0010							* call DSRLNK
BYTE >08								* DSR call, not Subprogram call
BS G@TRYAGAIN							* condition is SET if bad DSR name (try again just in case)
CALL G@CHECKERR							* test error byte
BS G@NOERROR							* all good

TRYAGAIN			
CZ VDP@>0DFF							* already fixed mode?
BS G@ERROR

ST VDP@>0D01,>0C						* change to fixed and...
CLR VDP@>0DFF							* clear the flag
BR G@OPEN								* try again

NOERROR
ST VDP@>0D00,>02						* change to read mode

READ
DST @>8356,>0D09						* set PAB pointer
CALL G@>0010							* call DSRLNK
BYTE >08								* DSR call
CALL G@CHECKERR						* check for error
BR G@DONE								* error terminates the read
	
CZ VDP@>0E00							* zero length filename?
BS G@DONE								* then we're done
			
CALL G@OUTPUT							* output this string to the screen
			
SCAN									* check keyboard
CEQ @>8375,>02							* FCTN-4?
BS G@DONE								* then exit
B G@READ								* then branch around and do it again!
			
CHECKERR
ST @>8300,VDP@>0D01						* get status byte
AND @>8300,>E0							* mask out error bits
CZ @>8300								* COND set if no error, reset on error
RTNC
			
ERROR
CALL G@>0036							* play error tone
CALL G@BLANKSCR							* blank line
MOVE >000C TO G@>5DE0 FROM G@DIRFAIL	* copy error to buffer
CALL G@EMIT								* display it then fall through

DONE
CALL G@CLEANUP							* close file, restore VDP and GROM banks
CALL G@>0012							* and return

EMIT 
* (shifts up the characters in the GRAM buffer and displays them, then calls SCROLL)
DST @>837E,>1702					* Row 23, col 3
DST @>8302,>5DE0					* GROM buffer

NEXTCHAR
MOVE >0001 TO @>8304 FROM G@>0000(>8302) * get a char (so wasteful!)
ADD @>8304,>60						* add offset
ST @>837D,@>8304					* put it on the screen
INC @>837F							* next column
INC @>8303
CEQ @>8303,>FC						* 28 chars processed?
BR G@NEXTCHAR

BLANKSCR
MOVE >0001 TO G@>5DE0 FROM G@LINE	* erase the line (first byte)
MOVE >001b TO G@>5DE1 FROM G@>5DE0	* erase the line (the rest of them)

* (copy of the scroll in GROM 2 - just as expensive to copy as remap the pages)
MOVE >02E0 to VDP@>0000 FROM VDP@>0020
FMT
	XPT=>00
	YPT=>17
	02'>7F'
	1C'>80'
	02'>7F'
END FMT

RTN									* and return

HEADER
CALL G@BLANKSCR					* need this for initialization
CALL G@DRAWLINE					* output the line (diskname/size/free)
CALL G@BLANKSCR					* two blank lines to fill in
CALL G@BLANKSCR
FMT
	SCRO >60	
	XPT=>02
	YPT=>16
	'FILENAME'
	X+=3
	'SIZE'
	X+=4
	'TYPE'
	x+=9
	1B'-'
ENDFMT
CALL G@BLANKSCR
RTN

CLEANUP
ST VDP@>0D00,>01						* change to close opcode
DST @>8356,>0D09
CALL G@>0010							* call DSRLNK
BYTE >08								* DSR call
CLR @>8342								* make BASIC happy
MOVE >0200 TO VDP@>0D00 FROM G@>5E00	* restore VDP
MOVE >0001 TO G@>1F12 FROM G@CFGPAGE	* map in the configuration block
MOVE >0001 TO G@>1F12 FROM G@>4004		* map the configured bank back in
RTN

OUTPUT 
*(read line at VDP@>0E00, screen output at VDP@>02E2)
* line buffer at GROM >5DE0 (28 bytes, ignores edge chars)
* this gets fixed up while emitting it
ST @>8301,VDP@>0E00					* length of name
ST @>8300,>0E						* vdp buffer pointer (points to end of name)
CLR @>8302							* making a 16-bit length
ST @>8303,@>8301					* save the name length
DINCT @>8300						* now points to first number (type)
DCHE VDP*>8300,>8000				* is it negative (protected?)
BR G@NOPROT
DNEG VDP*>8300						* remove protection flag

NOPROT
DCZ VDP*>8300						* is it zero? (should be header only)
BS G@HEADER						* yes, write header

DRAWLINE
MOVE @>8302 TO G@>5DE0 FROM VDP@>0E01	* write name into buffer
CHE @>8303,>0C						* 12 character or longer name?
BR G@SHORTNAME
CALL G@EMIT						* write and scroll now

SHORTNAME
*G@>5DF0 - type, we expect >400x, where x is 1 to 5
DINC @>8300							* second byte
ST @>8302,VDP*>8300					* get it
ST @>8305,@>8302					* save it for later
MUL @>8302,>07						* multiply by length of string - output in >02/>03
DADD @>8302,STRINGTAB				* make a pointer to GROM
MOVE >0007 TO G@>5DF0 FROM G@>0000(>8302)

*G>5DEB - second number, G@>0014 has number to string
DADD @>8300,8						* points to second number (size)
MOVE >0008 TO @>834A FROM VDP*>8300	* copy number to FAC
CLR @>8355							* TI BASIC format number
CALL G@>0014						* number to string
ST @>8302,@>8355					* pointer value
CLR @>8355							* fixup for length
MOVE @>8355 TO G@>5DEB FROM *>8302 	* write the number (single byte ptr in scratchpad?)

*G>5DF7 - record length (if type <> 5/program)
CEQ @>8305,>05
BS G@NOREC
DADD @>8300,9						* points to third number (record length)
MOVE >0008 TO @>834A FROM VDP*>8300	* copy number to FAC
CLR @>8355							* TI BASIC format number
CALL G@>0014						* number to string
ST @>8302,@>8355					* pointer value
CLR @>8355							* fixup for length
MOVE @>8355 TO G@>5DF7 FROM *>8302 	* write the number (single byte ptr in scratchpad?)

NOREC
* done, write, scroll and return
CALL G@EMIT
RTN

LINE 
*(for clearing the GRAM buffer)
BYTE >20
					
STRINGTAB
TEXT "  FREE:"
TEXT "DIS/FIX"
TEXT "DIS/VAR"
   TEXT "INT/FIX"
   TEXT "INT/VAR"
TEXT "PROGRAM"

DIRFAIL
TEXT "* DIR FAILED"

* the byte needed to map in the configuration bank
CFGPAGE		BYTE >11
* The byte needed to map in the SRAM bank
SRAMPAGE	BYTE >12

PAB 
DATA >001C,>0E00,>0000,>0000
DATA >6000,>2E2E

END

 

[twoodland]

Tursi, I love it! Is MPD available to install in a console? So cool to pick your flavor of TI.

[Tursi]

Tursi, I love it! Is MPD available to install in a console? So cool to pick your flavor of TI.

No, not yet. It's near the top of my task list to finish it off, though. I just want to put a couple more flavors into it.

[apersson850]

I've understood that moving the p-code card to a cartridge, or into the console, isn't exactly easy. So it will perhaps never happen. Anyway, just to remove one possible confusion: There's no GPL used on the P-code card. Reading some posts above I got the impression that some seem to think so.

[+Ksarul]

It has been done at least once--I loaded a copy of it into the GPL loader for my Geneve at the TI Treff in Berlin many years ago. It ran quite well--and at the time, it was the only functional p-System implementation that would run on a Geneve (it would also run using a Wiesbaden Supermodul on a regular TI--we tested that too). It was a beta that Alexander Hulpke was testing for the program's author (the author lived in Vienna), but unfortunately, he never released it--and Alexander kept iron control of his beta copy (as was proper), so no one at the Treff ended up with an unauthorized copy of it either.