Willsy

It's in Simplified 99/4 Assembly Language by Ken Culp.

... that the TI Assembler had a bit shift. Never read that in the ED/AS manual. As we all know, the assembler can resolve simple arithmetic at assembly time to calculate addressed, but I didn't know it could do bit shifts. The symbol // is used for a bit shift, and it does a right shift, shifting in zeros on the left: MSB EQU >8000 ; switch on MSB BIT14 EQU MSB//1 ; ooh! nice! BIT13 EQU MSB//2 ; splendid!

Chapter 5, section 5.6, page 162 is the start of the Assembly File IO in the attached book "Simplified 99/4 Assembly Language" by Ken Kulp. This is a brilliant book. I think you'll find it explains everything you need to know. It doesn't explain reading the disk catalog, but don't make that your first File IO project, choose something simpler to start with! Like, writing "hello mother" to a file, and then reading it back etc! Hope you like the attached. Mark 994a Assembly Language.pdf

I'll see if I can put some sort of document together if adamantyr doesn't beat me to it. Iirc its covered quite well in one of the assembly books. I'll look it up tomorrow .

You write a PAB in VDP memory, and set >8356 in pad to point to the length byte of your PAB. It's actually fairly easy to do in assembly language. Reading a catalog is a bitch, because the numeric data comes back in Radix 100 format. Doing things like relative file IO in assembly is quite simple once you get the hang of it. The trick is to write little subroutines that each do a little bit of work on the PAB. I generally 'work' on the PAB in normal CPU memory, then transfer it to VDP at the end, when I've finished setting it up. Eg. BL @OPCODE ; write an OPEN opcode to the opcode field DATA OPEN,MYPAB ; (byte 0) of the pab at address MYPAB LI R0,45 ; set record number 45 BL @SETREC ; call the 'set record' routine DATA MYPAB ; update the PAB at address MYPAB in cpu memory Once you have a little library of these helper routines, is very easy. Attached is a PDF that I made for myself some time that summarises the layout of PABs. Hope you find it useful! If you need to know anything, just go ahead and ask... Adam, Matthew, Tursi, Marc, myself etc will be happy to help. PAB Info.pdf

Just for kicks, I thought you might be interested to see the code to produce a checker board in TF : CHECKER 1 GMODE \ select 32 column mode 0 \ seed for display/dont display 19 FOR \ 20 rows (starts from 0) 23 FOR \ 24 columns (starts from 0) 1 XOR \ toggle the seed (1-->0 / 0-->1) DUP IF J I 42 1 HCHAR THEN \ display if seed >0 NEXT \ next column 1 XOR \ toggle the seed again NEXT \ next row DROP \ drop the seed ; Or, horizontally, in the more traditional Forth style: : CHECKER 1 GMODE 0 19 FOR 23 FOR 1 XOR DUP IF J I 42 1 HCHAR THEN NEXT 1 XOR NEXT DROP ; Takes just under 1 second (including setting the graphics mode and clearing the screen, which is done by GMODE), which is quite slow I suppose, but I wanted to use the same technique as the original poster. For speed, you'd want to use a similar approach to Sometimes (Sometimes is the master coder ): : 1LINE ." * * * * * * * * * *" CR ; : CHECKER 1 GMODE 0 19 FOR DUP IF SPACE THEN 1LINE 1 XOR NEXT DROP ; Flies! About a quarter of a second, again, that includes setting the VDP mode, and doing a screen clear, before it even begins to run your program Just thought i'd share. Sorry to hijack the thread http://www.youtube.com/watch?v=ftiFADkaDh0

Is it possible that the files you are trying to load are not TI BASIC files? Perhaps they are Mini Mem binary files (for example).

If you could post some photo's or scans that would be nice. Can you see a 74xx series chip there, too?

From what I understand, there are so few V2.2 consoles around that it's just not worth expending any energy on.

You're quite right Jacques. I should have just run the program! Actually, the program has some errors in line 1. It's impossible to output to disk as written. I modified the code as follows to produce output to a disk file: 1 CALL CLEAR :: A$="DSK3.OUTPUT" :: OPEN #1:A$,OUTPUT :: P=1 2 CALL CLEAR :: CALL PEEK(-31952,A,B,C,D) :: A=A*256+B-65536 :: C=C*256+D-65536 :: PRINT #P:" PROGRAM INFORMATION": :"Line Number Table" 3 PRINT #P: :"Start Address ";A:"End Address ";C: : :"Line Bytes Start":"Number Used Address":"------ ----- -------" 4 FOR I=C-3 TO A STEP-4 :: CALL PEEK(I,B,D,E,F) :: B=B*256+D :: E=E*256+F-65536 :: CALL PEEK(E-1,D) :: D=D+5 :: T=T+D 5 PRINT #P,USING "##### ### ######":B,D,E :: IF E THEN CALL SCREEN(6) :: GOSUB 7 6 NEXT I :: A=(A-C-1)/-4 :: PRINT #P: : :TAB(;"Total Bytes =";T:" Number of lines =";A:"Average Bytes/Line =";INT(T/A) :: STOP 7 RETURN 8 ! Note Variables: A$, P, A, B, C, D, E, F, and T are used in this program. which yeilds the following: PROGRAM INFORMATION Line Number Table Start Address -671 End Address -640 Line Bytes Start Number Used Address ------ ----- ------- 1 48 -67 2 128 -191 3 112 -299 4 103 -398 5 58 -452 6 111 -559 7 7 -638 8 80 -635 Total Bytes = 647 Number of lines = 8 Average Bytes/Line = 80

I believe there is a line number table? A small database where the line number is the key (presumably) and a single datum representing the beginning address of the line of code elsewhere in memory. By the way, did you see the GPL related programs on the TI Tech Pages? Well work look. http://nouspikel.group.shef.ac.uk//ti99/download.htm#disass Scroll down to the free software section. Some nice stuff. Mark

I'd rather read Jack Kerouac than use Facebook. That's how much I hate Facebook.

It would be nice wouldn't it? Even 1K, mapped (optionally) into the top of the cart memory space (>7C00 to >7FFF) would be nirvana. Anyone that has done any hard-core cart development will know exactly what I'm talking about. The option to page the memory in/out would be nice. However, the design looks to be in a very advanced stage of development. It may be too late. Also, looking at the PCB layout, it's getting wuite crowded. The only available space is in the bottom right hand corner. It may be possible to physically get a through-pin device into that space, but you've still got to get the tracks to it. It'd be tricky I reckon. Question: Was the board laid out manually or by using an auto-router? Perhaps an alternative to straight RAM might be a port mapped RAM? Using this approach some of the RAM on the Atmel could be used (it would need software to be written on the Atmel side). One could use the same technique as one uses to read/write VDP. Three memory addresses would be required: Address port (10 bits for 1K, might as well make it a 16 bit wide address) Write port (8 bits?) Read port (8 bits?) It's better than nothing! And would (presumably) require no changes to the current hardware design? Some sort of software handshake would be required, since the Atmel and the 9900 are free-running with respect to each other. For example, if you write an address to the address port, how does the Atmel know if you want to do a read or a write? Well, I suppose reads don't matter too much, it could just blindly do a read and populate the read port. But how does it know when you want to do a write? Something would need to be designed in to get around that issue, methinks! Anyway, I'm really looking forward to GROM read/write access in a cart. It's the perfect place for graphics etc, though with 512K of flash, we're not exactly short of space! Mark

I'm glad to see this game hasn't died! I'd like to port it to TF when it's done! A question: Your data. Is each datum an 8 bit item, or is there datum that could be > 255? If 8 bit data, then you need 56*26=1456 bytes. If the data is smaller than 8 bits, it can be bit-packed and un-packed when you need to read it. Rather than arrays (although I don't think they are particularly memory hungry) consider using strings to hold the data (one string per level, to get under the 254 character string limit?). Finally, if you do need 1456 bytes, then an obvious place to store that would be in VDP, since there is probably loads of free space in VDP memory. I don't know how XB uses VDP, but it might be possible to store your data in VDP after the end of the sprite table or something like that. You'll need a bit of assembly to provide POKEV and PEEKV to put/get the data, but that should be easy enough to do. Mark

Wow! Amazing job! Getting all that on a double sided board within the size constraints is really quite something. Hats off to the layout guy! Mark

My next task is to resurrect an old laptop that I have in the garage (it has a serial port) and install it as a permanent file server. I'll probably remove the hard disk completely, as they can't be trusted long term. I'll install Windows on a USB key and have it boot from that. I'll host all the TI files on an SD card. With such a setup, one can simply copy all their old floppy disks to the PC using subdirectories and not have to rely on 25 year old disk drives and disks. I'll go on the lookout for a really tiny (i.e. miniature) PC, one that I can attach to the back of the PEB. It can sit there with no keyboard or screen attached and just serve files from solid-state media. Nice!

Friends I decided to find out if Classic99 and a real 4A could work with the *same physical* files, hosted on a PC and served to the TI using Fred Kaal's HDX Server. The answer is yes. You can develop code on the PC, and when you want to test it on the real 4A, there is no need to transfer with a TIFILES header and run it through Archiver blah blah blah... Just connect the TI to the PC with a serial cable, and type OLD HDX1.<filename> You can then modify the *same* file *on the TI* if you want, and later re-load it in Classic99 to continue work! Fantastic. Here is a video proof-of-concept: Enjoy. This is a REALLY cool system. Much nicer than a nanoPEB in my view, because to transfer all your old 5.25" disk files to the PC with HDX you need to do nothing more than copy them using DM2K. Awesome. Mark

You wish is my command... I did a YouTube demo last night. See new thread

Yep, that's what it's for. It turns the PC into a file server. The files are hosted in a directory somewhere on the PCs hard disk (or on an SD card, or USB stick, or whatever). That's exactly right. As far as the console is concerned, its dealing with a disk drive. It has no idea that the RS232 card is being used. The HDX system covers level 2 and 3 DSR commands. Subdirectories are also supported. Yes. DM2K can utilise HDX (HDX is just another device, so you could equally use DSKU but I think DM2K offers some extra facilities Yes. Fred sells the little boards, and there is full instruction on how to build the boards and modify the RS232 card on Fred's website. There are a number of hardware options. I went for the modified RS232 option. One other option Fred sports is a new, custom PEB card with a 16550 UART on it. It would run at 115,000 baud. Much much faster than a disk drive - probably comparable to a hard disk in speed. Given your recent experience with the SID card, maybe you could put a board together? I'd certainly take one, maybe two! The TI99HDX page is here. Mark

I think you can. I'll try it later today just for kicks. HDX Server persists files in V9T9 format. Although Classic99 considers the V9T9 file format deprecated, it does support V9T9 files. In the latest versions of Classic99 you can set individual DSK folders to use either TIFILE or V9T9 files. This is very handy. I can tell HDX Server to use C:\Classic99\DSK0 as its disk folder, and set up classic99 DSK0 (through the user interface, no need to mess with ini files) to use V9T9 type files for DSK0. Then, you can seamlessly share files between your PC and TI. For example, if you write an XB program, or assembly language #3, or #5 file, *whatever* on the real TI, and save it to HDX1.whatever and it will actually go to Classic99s DSK0 folder in V9T9 format (because that is the format that HDX server uses). You could then load that file in Classic99 no problem at all. Of course, the opposite would also be true. A file created in Classic99 and saved to DSK0 would be written in V9T9 format, automatically in the correct format for HDX Server to work with, so the real 4A, connected to the PC via the serial port could IMMEDIATELY use the file. No translations necessary. The real 4A doesn't even 'know' that the file has come from a PC via the serial port. It's all abstracted away via the DSR. Awesome.

I think so as well, but I have no way to prove it. VIC-20 sounds low, considering it was the first computer model to break 1 million in sales. How is it the TI-99 beat the VIC in raw numbers? TRS-80 also sounds low, I would suspect at least 2 million sold because until the VIC-20, the TRS-80s were the top selling computer line. It's thought there were over 3 million TI-99/4As sold. It was the #1 machine in the USA for a while, before Commodore really got their prices down.

Talking of stuff like this, I just got one of Fred Kaal's HDX modified RS232 cards. Awesome. You run a server on your PC, connect the PC and the TI via RS232/2 and it gives you HDX1 HDX2 and HDX3. Subdirectories etc are supported. Absolutely-frickin-awesome! This is the model that I have. Mark

Unfortunately they are not, but they can be converted with some free software called TI99Dir (do a Google for Fred Kaal). It's worth pointing out that Win994A although very nice, is effectively no longer supported by its author. Classic99 is another great emulator (better than Win994A IMHO - ESPCECIALLY if you want to write software) and it natively supports the TIFILES format. Like Win994A, it is completely free, though the author will gladly accept a donation via his web site. See harmlession.com for the download page. Regards Mark

Yo need a hex editor for that. There's plenty of free ones on the web!

He he! After a good 10 or 15 years use they loosen up a bit and start to feel real nice!