DSR error 0094 when I try to use COPY directive in E/A II

[hhos]

I am trying to develop a simple disk format program that would load from cassette/WAV and format a SSSD disk in DSK1. I think I've gotten it pretty much done, but I decided to put in some screen output, which I thought would be easy, and I still think it SHOULD be. However, I put my character definitions into a separate file so I could use it in other future projects. Now, when I put a COPY directive in like this:

 

LABEL COPY "DSK1.CHASCII"

 

in my main source file, I get a "DSR error 0094". I don't know if I am misunderstanding the function of the COPY command, or I'm using a manual that is giving me the wrong syntax, or other. I am using the TI99 E/A manual, which I've found has a plethora of errata. As far as I can see I'm doing nothing wrong in using this command in this way, but I have tried single quotes and no quotes, which both give me a syntax error. I have also tried inserting and deleting a label, which is supposed to be optional, as well as a number of other combinations, all with no effect. I have started to think perhaps I've misread the purpose of the COPY command. It sounded like it should behave as an "include" or "use"(Microware OS9 and NitrOS9), each of which imports and assembles source as if the separate file was actually in the original file being assembled.(I've read that definition quite a few times and I can't see how it could possibly mean anything else) Is COPY something else? If so, that is one very big chunk of errata to add to the list. And, is there some other command that will provide this function for me? If it is indeed supposed to be an "include" what am I doing wrong?

 

Thank you,

HH

 

P.S. The main source assembles fine when I comment out the offensive COPY command line, and the "include" file assembles with only one error, saying that an "END" is assumed or some such. The include file is Matthew180's SCSI from his "Assembly on the 99/4A".

Edited December 7, 2018 by hhos

[+Lee Stewart]

You understand the COPY directive correctly. We cannot really see what is going on without seeing your code. Please post it.

 

...lee

[+FarmerPotato]

DSR ERROR 0094 is interpreted as follows:

00 - the operation, 0 for Open

94 - the Flag/Status byte. See E/A Manual page 293.

 

The bits of Flag/Status:

 

100 Error 4 - Out of table or buffer space on the device.

1 Record type VARIABLE

0 Data type DISPLAY

10 Mode INPUT

0 access SEQUENTIAL

 

This is equivalent to BASIC's I/O ERROR 04

 

The only reason I can think of to get Error 4, while opening a file, is too many files open.

I've never encountered this just by using a COPY directive in the main file.

You didn't by chance nest files with COPY directives did you?

 

I don't know how many disk buffers the E/A cartridge reserves, the usual default is 3, but it would need 4 disk buffers for Source, Object, List, and a COPY source.

Are you assembling with the L option on? (create LISTing file) Though I don't recall ever having problems creating a LIST file for a project with COPY directives.

[hhos]

DSR ERROR 0094 is interpreted as follows:

00 - the operation, 0 for Open

94 - the Flag/Status byte. See E/A Manual page 293.

 

The bits of Flag/Status:

 

100 Error 4 - Out of table or buffer space on the device.

1 Record type VARIABLE

0 Data type DISPLAY

10 Mode INPUT

0 access SEQUENTIAL

 

This is equivalent to BASIC's I/O ERROR 04

 

The only reason I can think of to get Error 4, while opening a file, is too many files open.

I've never encountered this just by using a COPY directive in the main file.

You didn't by chance nest files with COPY directives did you?

 

I don't know how many disk buffers the E/A cartridge reserves, the usual default is 3, but it would need 4 disk buffers for Source, Object, List, and a COPY source.

Are you assembling with the L option on? (create LISTing file) Though I don't recall ever having problems creating a LIST file for a project with COPY directives.

I didn't do any nesting of COPY directives, but I do almost always generate a listing when I'm working in assembly language. In this case I did so without giving it a single thought. I'm a bit too tired to trust myself to try this on such an unfamiliar machine tonight. I think I'll wait for morning to try assembling with just "R" as my option(s). It sounds very promising.

 

Thank you,

HH

[Tursi]

Good call on the number of buffers. I ran it up quickly in Classic99 and when the Assembler loads it sets the number of disk buffers to 4. That would seem to permit source, destination, listing and COPY. Are you working with hardware or emulation? If hardware, which hardware device? (The setting up of disk buffers is done by the DSR...)

[hhos]

Good call on the number of buffers. I ran it up quickly in Classic99 and when the Assembler loads it sets the number of disk buffers to 4. That would seem to permit source, destination, listing and COPY. Are you working with hardware or emulation? If hardware, which hardware device? (The setting up of disk buffers is done by the DSR...)

I'm running hardware. What good does it do to set up 4 disk buffers if the DSR is going to override your choices. That makes it look like COPY never did work, ... for 30+ years? At least with the original DSR ROM anyway, right? How could this problem not have surfaced before this? That makes no sense to me, though I have no better theory to present. As far as I know the disk controller is the original TI SSSD. I'll have a closer look inside later on tonight.

 

I tried assembling with just "R" for my option(s) and got the same result. Since I was using E/A II on FlashROM99 I decided to try assembling it with my original EA on floppy disk. Before I did that I checked the directory on the disk, just to get the correct file names so I wouldn't be filling up the disk needlessly, and everything looked fine. After the attempt at assembly my copy of EA, the entire floppy was trashed. I'm going to have to rewrite the whole thing because I didn't create a backup! That must be for the best, SOMEHOW! I'm not seeing it right now, though. Maybe that will teach me to start making a backup, like I used to do back in the day.

 

I searched through some of the stuff I bought years ago just after I bought this system. I found another assembler called the RAG assembler. I am certain I have read good things about this ASM on this forum. I have no printed manual, but there appears to be several files on the disks with manual-like text. I'm finding it hard to read on the TI screen and printing it out might not be much better. Besides I don't have anything set up to print it out anyway. Can anyone direct me to a tutorial/RAG-4-dummies that might be easier to read? My own search led me only to a manual for a GPL assembler. That's not for me. I think GPL is the biggest reason why the TI99 is so SLLLOOWWW. I didn't turn to assembly language on a Z80 forty years ago to go slow, and that hasn't changed because I'm looking at a different machine.

 

But I digress. At first I plan to just create a skeleton program with a COPY directive in it and try it with each assembler. If the problem is in the DSR ROM then the RAG will also have the same problem, unless the RAG programmer had a way to get around this little wrinkle. Either way it turns out, I'll have a better idea of how I'm going to get around this.

 

Thanks a lot for all the help.

HH

[Tursi]

I'm running hardware. What good does it do to set up 4 disk buffers if the DSR is going to override your choices. That makes it look like COPY never did work, ... for 30+ years? At least with the original DSR ROM anyway, right? How could this problem not have surfaced before this? That makes no sense to me, though I have no better theory to present. As far as I know the disk controller is the original TI SSSD. I'll have a closer look inside later on tonight.

It doesn't... generally. The reason I asked was that the DSR in question might have a bug. If it was Classic99, I was going to look at that. I'm pretty sure the TI DSR is fine.

 

Are you sure the disk just isn't full (either no free sectors or 127 files already)? That's the other reason for that error code...

[hhos]

I couldn't figure out how to get the controller out to get a good look at it. I was afraid of breaking it so all I can tell you is it is a TI disk controller.

 

HH

[hhos]

It doesn't... generally. The reason I asked was that the DSR in question might have a bug. If it was Classic99, I was going to look at that. I'm pretty sure the TI DSR is fine.

 

Are you sure the disk just isn't full (either no free sectors or 127 files already)? That's the other reason for that error code...

I know for a fact the disk was not full. Even after the error was first encountered I was able to assemble other versions of the same source, under different names, in an effort to determine the cause. I can no longer go back to check to see how much disk I still had left, but the only things on it were EDIT1, the source, object, and listings for two versions of my main file( the listing and object files for the "COPY" version were zero length and therefore only took up one sector each) and source, listing, and object for the "include" file.

 

Thanks,

HH

[+FarmerPotato]

I know for a fact the disk was not full. Even after the error was first encountered I was able to assemble other versions of the same source, under different names, in an effort to determine the cause. I can no longer go back to check to see how much disk I still had left, but the only things on it were EDIT1, the source, object, and listings for two versions of my main file( the listing and object files for the "COPY" version were zero length and therefore only took up one sector each) and source, listing, and object for the "include" file.

 

Thanks,

HH

 

It sounds like a corrupted disk. I think it is possible to trash sector 0, but still open files one more time before one big file write clobbers more of the disk.

 

You are starting with some pretty arcane DSR calls--is it possible that you ran your program at some point and it touched the disk you were using? I suspect a write to sector 0.

 

I think the usual course of learning TI-99/4A assembly is to learn everything about DSRLNK using PABs and record-level file access (Level 3 subroutines), before attempting the Level 1 operations (initialize, read sector, write sector) or Level 2 (direct file read/write) documented in the "GPL Interface Specification for the 99/4 Disk Peripheral".

 

 

 

Before you erase that disk and start over, would you like someone to attempt recovery of your data? I have experience in that (out of necessity).

[RXB]

 

 

I searched through some of the stuff I bought years ago just after I bought this system. I found another assembler called the RAG assembler. I am certain I have read good things about this ASM on this forum. I have no printed manual, but there appears to be several files on the disks with manual-like text. I'm finding it hard to read on the TI screen and printing it out might not be much better. Besides I don't have anything set up to print it out anyway. Can anyone direct me to a tutorial/RAG-4-dummies that might be easier to read? My own search led me only to a manual for a GPL assembler. That's not for me. I think GPL is the biggest reason why the TI99 is so SLLLOOWWW. I didn't turn to assembly language on a Z80 forty years ago to go slow, and that hasn't changed because I'm looking at a different machine.

 

 

Without GPL you do not even get a BOOT SCREEN or any Device Access.

With only 32K of RAM total and 16K of VDP the only way to pull off the things the TI can do is mostly due to GPL, that is just a simple fact.

Cartridge Menu is due to GPL, Device access is due to GPL though you can do it with Assembly but you are limited to DSR space only and only 1 DSR can be open at same time.

Cartridge RAM has the same exact issue as DSR of only 8K available.

 

Now today we can do more with Assembly using SAMS 1 Meg, but currently the only thing made for the TI to date is GPL that can swap SAMS memory without running from RAM problems.

Like DSR SAMS RAM has the same exact bottle neck and again GPL is the only real solution that has no problems talking to any memory be it VDP, RAM or GRAM/GROM.

 

Now I know GPL is slower then Assembly but Tursi has demoed that GPL could be as fast as C or Forth with the right hardware set up.

[RXB]

I couldn't figure out how to get the controller out to get a good look at it. I was afraid of breaking it so all I can tell you is it is a TI disk controller.

 

HH

Editor Assembler has buffers for use:

 

>1000 is for Assembler or Editor to be loaded and run

>1100 is for Source file input

>1200 is for Object file output

>1300 is for List file output

>1400 if for Printer or Wafer Tape or Tape output.

 

Now Load and Run option 3 and EA option 5 Program loader also run from >1000

 

Your DSR error could be a Compressed option error or check if you have a bad disk file already there not fully deleted.

Edited December 8, 2018 by RXB

[hhos]

 

It sounds like a corrupted disk. I think it is possible to trash sector 0, but still open files one more time before one big file write clobbers more of the disk.

.......

Before you erase that disk and start over, would you like someone to attempt recovery of your data? I have experience in that (out of necessity).

Too late. I already re-formatted it. I was getting a "device error". I concluded from that, that all was lost. I was surprised when it re-formatted without error. So far all the disks I've tried to format when I got "device error" were failures, with this one exception.

 

 

 

 

 

 

 

 

 

You are starting with some pretty arcane DSR calls--is it possible that you ran your program at some point and it touched the disk you were using? I suspect a write to sector 0.

It definitely happened when the assembler wrote to the disk. My program has never been run. It's too dangerous to the disk currently in the drive. One of the reasons I decided to put some output to the display was to prevent damage like what you describe. The plan was to start it, put up some rudimentary instructions, something like "Place a the disk in DSK1", "All data on the disk will be destroyed", "by the formatting process", "Press ENTER when ready."

 

 

 

 

I think the usual course of learning TI-99/4A assembly is to learn everything about DSRLNK using PABs and record-level file access (Level 3 subroutines), before attempting the Level 1 operations (initialize, read sector, write sector) or Level 2 (direct file read/write) documented in the "GPL Interface Specification for the 99/4 Disk Peripheral".

I started this project in response to a request from an Italian 99er, "ti99iuc". The request was made in 2011 and hopefully all his issues have already been addressed, but his fix for the problem was to send his Disk Manager to his fellow Italian 99er, so he could get some disks formatted. I had pretty much the same problem myself, which is why I found his request. I at first thought I could write a BASIC program to "poke" in some assembler to do the format. Then I went through some of the stuff I had bought for my TI99 years ago, and found a FlashROM99, so my troubles were over, at least in that respect. I am continuing with the project because I figure there could be more need for such a utility, but now it will be 100% assembler, and be distributable via cassette or WAV file.

 

I'm not inexperienced in assembly language, just TMS9900 assembly language. I wrote my own assembler for the TRS-80 Color Computer (hand assembled), complete with its own file system (I didn't understand RS's file system so I made my own) and low level format utility. Then I saw Radio Shack's macro assembler, bought it, and started using that, and then turned to OS9 and its even more capable assembler. This project would not have been a big deal for me back then, but I think I should be able to handle it now, even with my age-shrunken brain. I used to find it relaxing to take a break in the day and just program a computer for 15 minutes. Now it's more of a chore, but my brain needs some exercise, and I've become somewhat fascinated by the TI99 design. The question in my mind is this: How many times can they possibly shoot themselves in the foot?

 

But I'm rambling now. I think I would have finished this project long ago if the TI99 was more like the other platforms of its time. It is more advanced in many respects, and I think if they hadn't made so many mistakes they could have been the other major computer manufacturer to take on IBM's PC, or even been in IBM's place in home computer history.

 

Thanks for the offer of help with my little disk SNAFU,

HH

Edited December 8, 2018 by hhos

[hhos]

Without GPL you do not even get a BOOT SCREEN or any Device Access.

With only 32K of RAM total and 16K of VDP the only way to pull off the things the TI can do is mostly due to GPL, that is just a simple fact.

Cartridge Menu is due to GPL, Device access is due to GPL though you can do it with Assembly but you are limited to DSR space only and only 1 DSR can be open at same time.

Cartridge RAM has the same exact issue as DSR of only 8K available.

 

Now today we can do more with Assembly using SAMS 1 Meg, but currently the only thing made for the TI to date is GPL that can swap SAMS memory without running from RAM problems.

Like DSR SAMS RAM has the same exact bottle neck and again GPL is the only real solution that has no problems talking to any memory be it VDP, RAM or GRAM/GROM.

This almost sounds like you completely agree with me. The TI99 is completely hamstrung by the use of GPL as its primary language. All of this can be done with machine language. I know this because it IS done with machine language in the end. It looks to me like GPL was forced on us because they didn't put a decent quantity of RAM in the machine, and also because they might have thought we would never know the difference?

 

TI should not have tried so hard to compete with the Commodore PET. That's what killed them. If they had put just 4K in there they would have had a much better machine, without GPL. I think 48K, a full 16 bit bus, a monitor, and an 80 column display mode would have positioned them to take the business market. IBM might not have even gotten into the home and small business computer market, or they might have been forced come in with a much more capable first entry into the market. But probably, that's just me.

 

 

 

Now I know GPL is slower then Assembly but Tursi has demoed that GPL could be as fast as C or Forth with the right hardware set up.

Right off the bat I have a problem with, "with the right hardware set up." But then I don't have any idea how fast C or Forth can be on the TI99 either. I ran some tests in BASIC several months ago when I acquired some 20+ TI99's. I wish I had written the results down, but I didn't. I just remember that a CoCo1, running at .894886 MHz, blew the doors off the TI99, which was of course running at 3 MHz. A C64 was even faster than either the CoCo or the TI99. I think the TI99 BASIC should run at least 3 times faster than it does, but I'm not about to re-write the BASIC interpreter. I don't like BASIC either, but it can be a quick way to demonstrate/test an idea. (quick, not fast)

 

Where is this demo? What hardware set up?

 

Thank you,

HH

[RXB]

 

 

Thanks for the offer of help with my little disk SNAFU,

HH

I play World of Warcraft and the name of my Guild is SNAFU.

It was given to me by two guys that were number 3 Guild on Duskwood server during Classic WOW less then 9 months after they started WOW.

[+FarmerPotato]

I think it's great that you are trying this niche, that for whatever reason, nobody ever filled.

 

Here is some sample code that I looked back at yesterday.

 

https://github.com/olsone/tinet/blob/master/BBS-XMDS

This is the source for XMODEM protocol.

 

It calls Level 2 Disk routines from the GPL Spec. The usage examples might be helpful to you, without directly giving away the answer.

 

BL @FILE2

DATA >0114

 

for instance sets up the 014 DIRECT READ subroutine. You can imagine modifying it to set up and run subprogram 11.

The code also uses DIRECT READ as well as an OPEN and Level 3 read of DIS/FIX 128 file.

[RXB]

This almost sounds like you completely agree with me. The TI99 is completely hamstrung by the use of GPL as its primary language. All of this can be done with machine language. I know this because it IS done with machine language in the end. It looks to me like GPL was forced on us because they didn't put a decent quantity of RAM in the machine, and also because they might have thought we would never know the difference?

 

TI should not have tried so hard to compete with the Commodore PET. That's what killed them. If they had put just 4K in there they would have had a much better machine, without GPL. I think 48K, a full 16 bit bus, a monitor, and an 80 column display mode would have positioned them to take the business market. IBM might not have even gotten into the home and small business computer market, or they might have been forced come in with a much more capable first entry into the market. But probably, that's just me.

 

 

 

Right off the bat I have a problem with, "with the right hardware set up." But then I don't have any idea how fast C or Forth can be on the TI99 either. I ran some tests in BASIC several months ago when I acquired some 20+ TI99's. I wish I had written the results down, but I didn't. I just remember that a CoCo1, running at .894886 MHz, blew the doors off the TI99, which was of course running at 3 MHz. A C64 was even faster than either the CoCo or the TI99. I think the TI99 BASIC should run at least 3 times faster than it does, but I'm not about to re-write the BASIC interpreter. I don't like BASIC either, but it can be a quick way to demonstrate/test an idea. (quick, not fast)

 

Where is this demo? What hardware set up?

 

Thank you,

HH

Found the link in AtariAge on GPL and GROMs.

5,344 posts
HarmlessLion
Location:BUR
Posted Tue Apr 28, 2015 10:28 PM

I recently found my notes wherein I measured the read speed of GROMs (I was testing against the AVR GROM code I wrote). Running the AVR at 20MHz with an external clock, single reads were taking roughly 5 wait states to execute (just slightly slower than 8-bit RAM at 4 wait states). A normal GROM read takes over 25 wait states. Even with the 5:1 speed advantage on GROMs, a GPL program like TI BASIC has no visible speed improvement (yes, I removed all real GROMs from the system to run the test). (The 8MHz AVR [internal clock] takes about 14 wait states - still markedly faster). The point is that the GPL interpreter spends a lot more time reading CPU ROM than it does reading GROM, enough that a 5 times faster GROM chip is only marginally faster in practice. it doesn't take much time looking at TI Intern to see this is true -- count the CPU cycles between two GPL instructions, you'll see that it easily absorbs the slower speed of the GROM chip itself.

In a nutshell GPL is not the problem of speed it is where it is stored....GROMs are slow and TI Basic unlike Extended Basic has no ASSEMBLY ROMs for support (12K)

Also TI Basic totally runs from Slower VDP RAM ONLY unlike Extended Basic that runs XB programs from RAM in upper 24K.

This is why TI Basic is so much slower then Extended Basic.

 

I took the TI Basic RND function and put it into RXB to fix the slower Extended Basic RND:

 

[Tursi]

I feel like I'm being slightly misquoted... while GROMs are very slow (second slowest chips on the motherboard!), the slow speed of GPL has more to do with the interpreter, which I consider fairly inefficient, than the GROMs OR the VDP memory storage. Just rewriting the MOVE opcode not to set the address for EVERY SINGLE BYTE would improve the apparent speed of BASIC markedly. Some day I hope to get around to proving that.

 

I don't remember proving myself that it was comparable to C or Forth, but we did create a benchmark thread that went for a while, the results of that were here:

 

http://atariage.com/forums/topic/248187-benchmarking-languages/page-1

 

And the last post with a summary of results:

 

http://atariage.com/forums/topic/248187-benchmarking-languages/?p=3814275

 

(After that it drifted into alternate test ideas.) It puts GPL in the same class as the other languages, but still at the bottom. (But, not by enough to discount it.)

[RXB]

I think that is what I was saying Tursi.

 

"Now I know GPL is slower then Assembly but Tursi has demoed that GPL could be as fast as C or Forth with the right hardware set up."

 

That would mean upgrade of ROM 0 and GROMs in TI right?

[Tursi]

I think that is what I was saying Tursi.

 

"Now I know GPL is slower then Assembly but Tursi has demoed that GPL could be as fast as C or Forth with the right hardware set up."

 

That would mean upgrade of ROM 0 and GROMs in TI right?

The impression I got from your message was that the VDP and GROM access speed were the reason, and I don't agree with that part of it. At least not /technically/. The way they do it, definitely, but not because of the hardware. But it's all opinion until it's proven.

 

Yeah, improving the interpreter would mean replacing ROM0, and since that's soldered, I've never been really motivated to try it.

[RXB]

The impression I got from your message was that the VDP and GROM access speed were the reason, and I don't agree with that part of it. At least not /technically/. The way they do it, definitely, but not because of the hardware. But it's all opinion until it's proven.

 

Yeah, improving the interpreter would mean replacing ROM0, and since that's soldered, I've never been really motivated to try it.

Hmm what about a Classic99 version to see results???

 

I think everyone would be pretty interested to see just how much faster it would perform especially XB or TI Basic?

 

Also would speed up my GPL Compiler for me....

Edited December 10, 2018 by RXB

[+FarmerPotato]

I feel like I'm being slightly misquoted... while GROMs are very slow (second slowest chips on the motherboard!), the slow speed of GPL has more to do with the interpreter, which I consider fairly inefficient, than the GROMs OR the VDP memory storage. Just rewriting the MOVE opcode not to set the address for EVERY SINGLE BYTE would improve the apparent speed of BASIC markedly. Some day I hope to get around to proving that.

 

I don't remember proving myself that it was comparable to C or Forth, but we did create a benchmark thread that went for a while, the results of that were here:

 

http://atariage.com/forums/topic/248187-benchmarking-languages/page-1

 

And the last post with a summary of results:

 

http://atariage.com/forums/topic/248187-benchmarking-languages/?p=3814275

 

(After that it drifted into alternate test ideas.) It puts GPL in the same class as the other languages, but still at the bottom. (But, not by enough to discount it.)

 

Since this has wandered far from the thread topic (using the Editor Assembler COPY directive!) could everyone instead post on the existing benchmarking thread to talk about GPL speed?

 

Thanks

[hhos]

I know for a fact the disk was not full. Even after the error was first encountered I was able to assemble other versions of the same source, under different names, in an effort to determine the cause. I can no longer go back to check to see how much disk I still had left, but the only things on it were EDIT1, the source, object, and listings for two versions of my main file( the listing and object files for the "COPY" version were zero length and therefore only took up one sector each) and source, listing, and object for the "include" file.

 

Thanks,

HH

Oops, forgot that I also copied ASSM1 and ASSM2 onto that disk before trying the assembly. They seemed to load without problem and then afterward I could access nothing on that disk. The disk was also a 1.2 MB HD disk, formatted as SSSD(90K), so that could well have been a part of that problem, even though I had not had a problem with it up to that point. What can I say? I was warned about that. I have now formatted 15+ DSDD disks as SSSD's so I shouldn't have to worry about THAT happening again.

 

Thanks,

HH

[hhos]

 

Since this has wandered far from the thread topic (using the Editor Assembler COPY directive!) could everyone instead post on the existing benchmarking thread to talk about GPL speed?

 

Thanks

Sorry about that, FarmerPotato. I think it was me that started that. Thank you for the source for the Xmodem program. It's kind of distracted me from my original goal, but it's raised some points that I need to address, or just want to. I'll post any other questions on those to another thread, and try not to clutter this one up too much again.

 

Thanks,

HH

Edited December 11, 2018 by hhos

[hhos]

Editor Assembler has buffers for use:

 

>1000 is for Assembler or Editor to be loaded and run

>1100 is for Source file input

>1200 is for Object file output

>1300 is for List file output

>1400 if for Printer or Wafer Tape or Tape output.

I think your memory map is in error, but I can't seem to locate the document where I read about this. I know that a copy of the File Descriptor Record(FDR) is copied into the VDP memory space. I'm a little bit shaky on what the copy is called, but I'm calling it the FCB here. Doesn't there have to be a 256 byte space in there for the FCB for each open file? It is possible for the buffers to be shared, even if it is a bit messy, but I'm reasonably certain that the TI99 reserves 512 bytes in VDP for each file.

 

Does anyone know where to find an authoritative source of information on this?

 

Thank you,

HH

Edited December 11, 2018 by hhos