At least ! DSK image from my collection

[rocky007]

At least after nearly 1 year, i converted my first TI 99 into .DSK image !

 

I was like Moïse : i tried first to connect in my CF9+ and PEB in same time, designed a PCB to use both in same time, and of course, it didn't worked.

 

I also bought several 5"25 disk drives for PC to use Omnilfop, but no one worked good. I found a old laptop with 3"1/2 inside, so i decided to buy a 3"1/2 for TI99. I lost many time to connect him to Pebox because something was wrong. I tought first about the disk controller. Thanks again to Marc for his help and the shipment of a disk controller.

After many test, it seems flexcable was defective and not disk controller.

 

I searched a complete Pebox with flexcable. Found a brand new on Tex Treasure, connected my 3"1/2 and everything at least worked good !

 

I converted my first disk today : TI Basic compiler ( Peter Kull version, i never saw on internet )

ticompilier.zip

Edited August 6, 2011 by rocky007

[rocky007]

and a very beautiful slideshow :

slideshow.zip

[rocky007]

a compilation of nice mini memory games... it works on real TI99, but don't find a way to run with classic 99

 

this compilation is a mystery for me... MM-LOAD is used to load games into mini memory.

To start the game, go to mini memory, option "RUN" , program name : "START"... but for what "MM-SAVE" ??

mm-games.zip

Edited August 6, 2011 by rocky007

[+OLD CS1]

a compilation of nice mini memory games... it works on real TI99, but don't find a way to run with classic 99

 

this compilation is a mystery for me... MM-LOAD is used to load games into mini memory, and then start the game with "RUN" option of mini memory... but for what "MM-SAVE" ??

 

I am hoping it is a program to dump MiniMemory RAM to disk. I need that, badly, for one of my old BASIC games.

[rocky007]

this i understand... but in that case, the games to load ( & save ) to mini memory are not in basic.

Edited August 6, 2011 by rocky007

[+OLD CS1]

this i understand... but in that case, the games to load ( & save ) to mini memory are not in basic.

 

Probably, but the code should be CALL LINK'able or at least dissectable.

[+acadiel]

a compilation of nice mini memory games... it works on real TI99, but don't find a way to run with classic 99

 

this compilation is a mystery for me... MM-LOAD is used to load games into mini memory, and then start the game with "RUN" option of mini memory... but for what "MM-SAVE" ??

 

I am hoping it is a program to dump MiniMemory RAM to disk. I need that, badly, for one of my old BASIC games.

 

Have you tried using EasyBug to dump the memory to cassette and then using a program like DIskIt to make a disk image?

 

There's also a nice disk of Mini Memory programs that I have that might have something that will help... see attached.

mmprogs.dsk.zip

MAPLE_LEAF.dsk.zip

Edited August 6, 2011 by acadiel

[+OLD CS1]

 

Have you tried using EasyBug to dump the memory to cassette and then using a program like DIskIt to make a disk image?

 

There's also a nice disk of Mini Memory programs that I have that might have something that will help... see attached.

 

I have cassette dumps of the memory, but I never had access to anything which could be used for conversion until recently. What I need is to be able to CALL LOAD() the file into MiniMemory then be able to CALL LINK() the programs. It is a mix of programs and data.

 

I will give these a shot. Thanks.

[rocky007]

WOW ! i tested the TI BASIC compilator today... in fact it's not TI BASIC compiler, but TI EXTENDED BASIC compiler !!!

i made some test ( Sprite, display at, etc..), everything worked perfect !

 

Little video :

 

http://youtu.be/GntF-hIeqRQ

 

So, somebody have a idea how to start the compiled version without through the special loader ?

 

Here it is the sprite demo compiled.

 

 

 

I also discovered a disk i received very gently from Eric Lafortune ( rockrunner ) when i was young.

There are some nice games

 

To start : load the game under TI Basic with Mini Memory, then the TI will reset , go to mini memory and selectr "RUN"

SPRITE@.zip

ericdisk.zip

Edited August 7, 2011 by rocky007

[+OLD CS1]

WOW ! i tested the TI BASIC compilator today... in fact it's not TI BASIC compiler, but TI EXTENDED BASIC compiler !!!

i made some test ( Sprite, display at, etc..), everything worked perfect !

 

Could this be the mythical compiler which actually supports sprites, then? I believe this was mentioned in another thread, and if it is and does work, this could preclude my transition to C and GPL. At least for a while.

[rocky007]

Could this be the mythical compiler which actually supports sprites, then? I believe this was mentioned in another thread, and if it is and does work, this could preclude my transition to C and GPL. At least for a while.

 

this one support sprites for sure !!!

 

So i have a question : why some BASIC program are "PROGRAM" filetype, and some other are "INT/VAR" filetype ? Is it depending of the size ?

The compiler only accept "INT/VAR" filetype

Edited August 7, 2011 by rocky007

[+OLD CS1]

this one support sprites for sure !!!

 

So i have a question : why some BASIC program are "PROGRAM" filetype, and some other are "INT/VAR" filetype ? Is it depending of the size ?

The compiler only accept "INT/VAR" filetype

 

I believe that is MERGE format. Anyone?

[Tursi]

Wow... nice find!

 

Yeah, PROGRAM image is used up until 12 or 13k, IIRC, then it switches to INT/VAR254. Which one it uses actually depends on how much VDP memory is free, but I'm not sure an easy way to convert from PROGRAM to INT/VAR (unless you use Rich's modified XB, which ONLY saves in INT/VAR format...?)

[rocky007]

Wow... nice find!

 

Yeah, PROGRAM image is used up until 12 or 13k, IIRC, then it switches to INT/VAR254. Which one it uses actually depends on how much VDP memory is free, but I'm not sure an easy way to convert from PROGRAM to INT/VAR (unless you use Rich's modified XB, which ONLY saves in INT/VAR format...?)

 

in fact i wanted the inverse : INT/VAR to PROGRAM ( compiler only recognize PROGRAM )

Edited August 8, 2011 by rocky007

[+acadiel]

 

Have you tried using EasyBug to dump the memory to cassette and then using a program like DIskIt to make a disk image?

 

There's also a nice disk of Mini Memory programs that I have that might have something that will help... see attached.

 

I have cassette dumps of the memory, but I never had access to anything which could be used for conversion until recently. What I need is to be able to CALL LOAD() the file into MiniMemory then be able to CALL LINK() the programs. It is a mix of programs and data.

 

I will give these a shot. Thanks.

Did any of the Mini memory programs on the disk help, CS1?

Edited August 12, 2011 by acadiel

[+OLD CS1]

Did any of the Mini memory programs on the disk help, CS1?

 

I sadly have not had the time, yet. Been busy cleaning up the house, garage, working break-fix, and helping a couple of colleagues all week. Maybe this weekend, since I have absolutely nothing planned.

[sometimes99er]

a compilation of nice mini memory games... it works on real TI99, but don't find a way to run with classic 99

Works fine with Classic99.

 

[rocky007]

ah yes with CALL INIT it works

[+OLD CS1]

Did any of the Mini memory programs on the disk help, CS1?

 

The mm-save and mm-load programs will be useful. They are not anything special, in the sense that mm-save just PEEKs memory and dumps it to a file*. However, mm-load apparently sets up a VDP PAB and calls a short ML routine which loads said files into RAM. That routine will definitely suit my purposes as it is fairly quick to load 4k of memory. Thank you for posting these disks up.

 

For this old game I just need to clean up the Mini Memory RAM I used for my ML routines and data. I would like to re-write my routines to be relocatable so they can be loaded using CALL LOAD. Ultimately, it would be nice to re-write the game entirely in ML, though I have considered GPL of late.

 

Though, rather than re-write my old stuff I think I may just compile them and start my foray into ML, GPL, C, and Forth with some new ideas.

 

* Edit: the mm-save program on the games disk actually uses an ML routine as well to dump memory.

[sometimes99er]

There's also a nice disk of Mini Memory programs that I have that might have something that will help... see attached.

 

Browsing thru mmprogs.dsk.zip

 

 

[+OLD CS1]

The "Boulder Dash" demo (mmprogs.dsk -> DEMO) is quite interesting. It uses a view-port and has a number of multi-colored beasties. According to the documentation for "Rock Runner" on the other disk, it uses an undocumented graphics mode. Pretty neat-looking game, though I was unable to get "Rock Runner" to start.

 

GIF of action

 

 

 

(BTW, is there a video capture codec in Classic 99 which does not introduce artifacts? The uncompressed frames mode crashes the program on my system running XP x64.)

[+OLD CS1]

The mm-save program is pretty interesting, and simple in many regards. It is also easy to modify for customized usage.

 

(NOTE: I did not follow the proper program flow below, but the facts are still solid.)

 

First it makes a "copy" of the top 32 bytes of the MiniMemory cartridge RAM by placing them into variables, then copies into E0-E1 and sets the Last Free Available Memory (LFAM) address just under the REF/DEF table described next. A short routine gets set up which copies all of the MiniMemory RAM into VDP RAM, and REF/DEF entry for the routine, and is then called via CALL LINK("A").

 

After you give the BASIC program a file name, it replaces the CPU-to-VDP copy routine with a routine which calls DSRLNK with a pointer to the location in VDP RAM which will hold the file name set up next. It then sets up what appears to be a peripheral access block including the file name with "DSK1." prefixing.

 

I do not know the construction of a PAB nor how DSRLNK works, but I assume that DSRLNK takes >1F09 passed to it and truncates the LSB to ascertain the PAB start (as >1F00,) then >0600 means "SAVE", >2000 is the start address in VDP RAM, >0000 is some kind of flag, >1000 is the length of data to save, and the trailing >0000 is another flag.

 

Finally, the top 32 bytes of the MiniMemory cartridge RAM destroyed above and the original LFAM pointer are restored.

 

Below I broke down the BASIC LOAD and VPOKE statements using the mmprogs.dsk:mmdisassem program. Neat program, though it did not correctly disassemble the data after the DSRLNK call (it disassembled into DATA >0000 when it should have been DATA >0008.)

 

 

100 CALL CLEAR
110 PRINT " MINI-MEMORY DUMPPROGRAMMA   *************************"
120 PRINT ::::::::::
130 DIM KAR(10)
140 CALL PEEK(32736,A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,C0,C1,C2,C3,C4,C5,C6,C7,C8,C9)
150 CALL PEEK(32766,D0,D1)

>7FE0->7FFF into A0-A9, B0-B9, C0-C9, D0-D1

160 CALL PEEK(28702,E1,E2)
170 CALL LOAD(28702,127,248)

701E (LFAM) into E1-E2
701E (LFAM) >7F, >F8

180 CALL LOAD(32760,65,32,32,32,32,32,127,14*16)
>7FF8 "A     ",>7F, >E0

190 CALL LOAD(32736,2,0,32,0,2,1,112,0,2,2,16,0,4,32,96,40,4,91)
AORG >7FE0
LI R0,>2000
LI R1,>7000
LI R2,>1000
BLWP @>6028	VMBW (copy >7000->7FFF to V>2000)
B *R11

200 CALL LINK("A")
210 INPUT "WELKE FILENAME KIEST U ?    DSK1.":A$
220 IF LEN(A$)>10 THEN 210
230 FOR I=1 TO LEN(A$)
240 KAR(I)=ASC(SEG$(A$,I,1))
250 NEXT I
260 CALL POKEV(7936,6,0,32,0,0,0,16,0,0,5+LEN(A$),68,83,75,49,46,KAR(1),KAR(2),KAR(3),KAR(4),KAR(5))
270 CALL POKEV(7956,KAR(6),KAR(7),KAR(,KAR(9),KAR(10))

FN=len(FILENAME), FNx=substr(FN,x)
V>1F00 >06, >00, >20, >00, >00, >00, >10, >00
V>1F08 >00, 5+FN,"DSK1." , FN1
V>1F10 FN2, FN3, FN4, FN5, FN6, FN7, FN8, FN9
V>1F18 FN10

280 CALL LOAD(32736,2,0,31,9,200,0,131,86,4,32,96,56,0,8,4,91)

AORG >7FE0
LI R0,>1F09
MOV R0,@>8356
BLWP @>6038	DSRLNK
DATA >0008	DSR linkage
B *R11

290 CALL POKEV(12256,A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,C0,C1,C2,C3,C4,C5,C6,C7,C8,C9)
300 CALL POKEV(12286,D0,D1)

V>2FE0 values from >7FE0->7FFF
** These are the top of MiniMemory values replaced by copy routine

310 CALL POKEV(8222,E1,E2)

V>201E values from >701E (LFAM)

(At this point, VDP RAM >2000->2FFF contains an exact copy of >7000->7FFF)

320 CALL LINK("A")
330 PRINT "MINI-MEMORY IS NU GEDUMPT   ONDER DE NAAM :";"DSK1."&A$

340 CALL LOAD(32736,A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,C0,C1,C2,C3,C4,C5,C6,C7,C8,C9)
350 CALL LOAD(32766,D0,D1)
360 CALL LOAD(28702,E1,E2)

Restore >7FE0->7FFF and >701E (LFAM)

370 END

 

 

I will play with the mm-load program later, but I suspect it does similar but reversed. These definitely fit my game purpose, though I think I may have a problem getting 4k of buffer space for my data to load. (I actually think I only need about 2k, but even so I should be able to break it down into parts -- maybe 256 or 512 bytes, or 1k at a time.)

 

I also think there is a more proper way to set up file buffers and PABs than this static method. There is a more proper way to allocate PAB and file buffer by using GPLLNK routine >0038 (Get String Space.)

[Tursi]

The "Boulder Dash" demo (mmprogs.dsk -> DEMO) is quite interesting. It uses a view-port and has a number of multi-colored beasties. According to the documentation for "Rock Runner" on the other disk, it uses an undocumented graphics mode. Pretty neat-looking game, though I was unable to get "Rock Runner" to start.

 

The "undocumented" mode is the now-famous "half-bitmap". It is not actually a new graphics mode, but rather bitmap mode configured with (documented, but harder to find) mask registers that make it a 256-character mode instead of a 768-character mode, so you get the convenience of normal Graphics 0 mode with the extra color support of bitmap. (Basically, you get 256 characters each of which can have a different color set per horizontal line).

 

(BTW, is there a video capture codec in Classic 99 which does not introduce artifacts? The uncompressed frames mode crashes the program on my system running XP x64.)

 

Classic99 uses the video codecs on your machine, so it's completely dependent on that. However, it uses a 16-bit internal rendering mode that relatively few codecs today support (and even some that do crash). Uncompressed /should/ work, however it's very performance and disk intensive and may be exposing issues elsewhere in the machine. PC Video tends, in my experience, to be flakey at the best of times.

 

Eventually, when I rework the VDP, the internal rendering will go 32-bit like the rest of the world uses today, but at the time I did it, 16-bit was fastest on my video card.

 

I've had relatively good luck using XVID, which is open, and you can tune the compression parameters to what you like, but it will still artifact. There may be pixel-perfect compressors out there these days, but I haven't followed PC video much.

[rocky007]

The "undocumented" mode is the now-famous "half-bitmap". It is not actually a new graphics mode, but rather bitmap mode configured with (documented, but harder to find) mask registers that make it a 256-character mode instead of a 768-character mode, so you get the convenience of normal Graphics 0 mode with the extra color support of bitmap. (Basically, you get 256 characters each of which can have a different color set per horizontal line).

 

I never noticed this special mode until today... and on CS1 capture, it looks really amazing. Is other games/programs use this special mode ?

Have u some source about docs ?

[Tursi]

I think Boulder Dash was the only well spread title that used it, it was definately the one that got everyone talking.

 

In truth it performs about the same speed as regular full bitmap mode does, but it takes less memory, since you only need one character set, while full bitmap needs three. Unfortunately, the masking causes problems with the sprites, leaving you with only 8 fully working sprites.

 

The masking (and the sprite problem) is briefly mentioned in TI's Video Display Processor's Programmer's Guide, but this document doesn't go to great depth and is provided more for evidence that it WAS documented. I put a copy here: http://harmlesslion.com/temp/Video%20Display%20Processors%20-%20Programmer's%20Guide.pdf

 

Thierry Nouspikel has a great description of how the masking works and numerous ways to use it on his VDP page here: http://nouspikel.group.shef.ac.uk/ti99/tms9918a.htm (scroll down the Hybrid Modes section under Bitmap). It's a little complex, which may be why the Editor/Assembler manual just glossed over it.

 

I wrote a little test app and showed the sprite issues on real hardware (it doesn't happen in emulation yet) here: http://www.youtube.com/watch?v=XJljSJqzDR0, skip ahead to 7:10 or so.