Willsy
-
Content Count
3,144 -
Joined
-
Last visited
Posts posted by Willsy
-
-
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
-
2
-
-
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.
-
2
-
-
My understanding has always been that a line number is somehow linked to its location in memory. I have always thought of it as two tables, a line number table and a memory location table that were linked. I wonder if line 2 of the SP program gives the answer.
A*256+B gives you a line number and subtracting 65536 from this gives you the position in memory where this line is stored. Likewise C and D minus 65536 gives you the position in memory where the line ends and is immediately before where the next line will start. This compensates for the line length that can vary.
We know that lines are recorded in the order entered and that this includes corrections to existing lines. I have no idea whether or not the line number table is kept in numerical order. Perhaps it is a linked listing.
I would think that both TI Basic and XB handle this process in the same way, I wonder if the TI Intern book or the Thierry site would have a more technical explanation than I am able to give. I am very much of a novice in this area so please accept my apology if my understanding is faulty.
Jacques
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 -
The search for line number 55 does not exist in GPL, it is in Assembly does anyone know how it finds it?
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.
-
I'm trying to imagine a cart with some CPU RAM. Gonna happen or not ??
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
-
2
-
-
Do me a favor and start a thread extolling the virtues of this beastie. See if there is any interest.
You wish is my command... I did a YouTube demo last night. See new thread
-
That looks pretty cool. I never realized that that is what the card was. If I understand correctly...
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).
With this card in place, all a person would have to do is "SAVE HDX1.name" or conversely "OLD HDX1.NAME" from a TI and the card and PC will take care of the rest ? If so then this would seem to solve most of the problems encountered with the NANO PEB not playing nice with the PEB.
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.
Any idea if Fred's DM2K can utilize the HDX ? And....Does Fred sell these devices and cables ?
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
-
That is very cool. Can you point HDX1 at the DSK1 directory under Classic99? That would be neat.
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.
-
1
-
-
TI99/4A figures a bit surprising, I'd have thought somewhat less.
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.
-
I think there is also another program out there that lets you use your PC's file system as a disk on the 99/4A, but I can't remember the name. It uses the serial port, makes a virtual disk on the 99/4A side, and reads/writes files directly to the hard disk on the PC side.
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
-
1
-
-
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
-
1
-
-
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!
-
I bought a SID card from Marc a couple of weeks ago. A really lovely design and works perfectly. Yes they are a little pricey but that's the nature of small hobby hardware runs. It was a ballsy project - hats off to Marc and all concerned that contributed to make it happen.
I'll finish the TF support for it when I get a chance... personal stuff is conspiring against me at the moment and for now finishing the TF book is priority #1
For anyone that wants a SID card, just check out Marc's site... they're for sale right there!
Mark
-
-
It creates assembler source that you then have to assemble with editor assembler. Speed seems quite good. It's quite hungry for memory though. The development cycle is torture, but not too bad if you have everything installed on a ram disk.
-
I know this game but never played it yet. Looks really promising!
Best wishes for your progress!
Btw: The Gameboy version has a size of 24KByte.
kl99
for sure using assembler & bitmap, it could use 5 ko, but unfortunally iu never studied assembler
in V1, i had to precalculate all pipe, with all level of water, in all ways possible ! ( 19 tubes X 9 waters postions, on 4 chars = 684 chars ! )
oh, i never studied tms9900 assembler as well (just 68k assembler).
i guess you are currently using Extended Basic?
can't the water be animated as sprites on top of the background-pipes?
at least as long as it's not completely filling up one pipe char?
afterwards you could replace the not filled version of the pipe char with a filled version of it and get rid of the sprite.
kl99
yes it's XB, but as i will compile it, i can't use sprite at all
anyway, it change nothing for V1 : i need empty + filled pipe for all positions : 4 corners + 2 straights + 4 cross + 4 starting point = 14 x 8 chars = 112 chars. and i don't count 4 for cursor & 4 for animated water
[brag]
In turboforth you get 256 characters, plus another (different) 256 characters for your Sprites!
[/brag]
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
File I/O in assembly language
in TI-99/4A Development
Posted
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.
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