FarmerPotato

Hey! Nice work! Back in 1989 I bought some of the Star Fleet Technical disks at a computer fair. They're long gone though. Anyhow you will quickly surpass what was on those. I made a bitmap mode, proportional font, text-only Starfleet Officer Exam with about 80 multiple choice questions. It doesn't have any pictures. Maybe we could combine things together?

I know I have one backplane in my garage, kept from tearing down a non-powering up P-Box.

I'm considering this TI Silent 700, a 1970s data terminal with Thermal Printer. It's a bit of a trek for me, but not too far past where the boys go to horse lessons. https://austin.craigslist.org/ele/d/elgin-vintage-texas-instruments-silent/6794316675.html

In the FORTH groups I listen to, the Jupiter Ace comes up often enough. It appeals to me enough to consider $600 for a display model (by that I mean one that I display in public). It's got a story. However, despite owning all the hardware to run the retro FPGA Jupiter Ace with video, I have not played with it yet. Too little time. I have spent $600 on items for two TI-99/4 systems, twice. Somebody out there loves Jupiter Ace that much.

Operating a Myarc WDS-100 drive enclosure without the top case, because the drive starter coil was failing and required manual intervention to start the drive. Wrapped my fingers around the power supply AC input socket, which had exposed conductors.

Here is a dsk and the files, created as EA5 in xdt99. xas99.py -R -i 99tro.a99 xdm99.py 99tro2.dsk --initialize 360 -n 99TRO xdm99.py 99tro2.dsk -a 99tro.bin xdm99.py 99tro2.dsk -a 99trp.bin xdm99.py 99tro2.dsk -a 99trq.bin I fixed some bugs in 99tro. Only the patched 99tro.a99 is included. - Turn interrupts off, set ws, before beginning any vdp writes - Garbage sprites now disabled during setup. - Sprite pattern for robot is >10 not decimal 10 - Correct size of spratt, so unwanted sprites stay disabled - Correct size of sprite name table so robot gets defined - vdp register 7 was a write to reg F. Changed 0F01 to 07F1 making background black (was undefined, probably green. not sure what effect writing to reg F has.) I didn't see the reported green bar in the scrolling area. but I suspect it was from the reg 7 default of Fweb loader. but I don't see transparent color being written there... I don't see the robot's left eye in the char patterns, and it doesn't blink like the right eye. Both blink in the Youtube video. Not sure how to explain that. I'm not fixing the left eye. Er, the robot's right eye. On your left. I'm not fixing the eye. 99tro2.zip

I used my 5V1A laboratory bench supply for the nanoPEB. I see the nanoPEB drawing no more than 75 mA while actively loading files and running a game. After 3-4 hours that would total about 1300mAh. Is that consistent with your battery life?

I could not find my power supply, so I used my laboratory bench supply at 5V 1A. I see the nanoPEB drawing no more than 75 mA while actively loading files and running a game. The important thing is to get a clean 5V regulated supply, but even a modest 500mA USB source would supply plenty of current.

How about making a torrent for Gamebase? I would join that.

FYI, to access the other port, change RS232 to RS232/2. I checked my (1 year old) nanoPEB v1 and found these devices in the DSR ROM (devices on same line are aliases) RS232, RS232/1 RS232/2 PIO, PIO/1 PIO/2 RS232/3 nanoPEB dsr 4000 aa01 4002 0000 4004 4010 power up list 4006 0000 4008 4016 dsr list 400a 0000 400c 406c interrupt * power up header 4010 0000 4012 40f2 4014 0000 * dsr headers 4016 4020 link to next 4018 4164 address 401a 0552 name: 'RS232' 401c 5332 401e 3332 4020 402c link to next 4022 4164 address 4024 0752 name: 'RS232/1' 4026 5332 4028 3332 402a 2f31 402c 4038 link to next 402e 416a address 4030 0752 name: 'RS232/2' 4032 5332 4034 3332 4036 2f32 4038 4040 link to next 403a 4154 address 403c 0350 name: 'PIO' 403e 494f 4040 404a link to next 4042 4154 address 4044 0550 name: 'PIO/1' 4046 494f 4048 2f31 404a 4054 404c 415a 404e 0550 name: 'PIO/2' 4050 494f 4052 2f32 4054 4060 4056 4176 4058 0752 name: 'RS232/3' 405a 5332 405c 3332 405e 2f33

10 OPEN #1:"RS232.BA=2400.PA=N.DA=8",UPDATE 20 INPUT #1:A$ 30 NL$=CHR$(13)&CHR$(10) 40 PRINT #1:"HELLO SAILOR"&NL$ 50 CLOSE #1 eliminate 20 if its not getting anywhere and put in a 50 GOTO 40 or try 10 OPEN #1:"RS232.BA=2400.PA=N.DA=8",UPDATE,DISPLAY,VARIABLE 1 This is from memory, I syntax checked it on my NanoPEB v1, but I can't find a DB9 serial cable. You can substitute your baud rate in BA=2400 but I figure why not start slow. Likewise PA=E.DA=7 would be 7 bits even parity . The TI RS232 checks two letters so you can write 10 OPEN #1:"RS232.BAUDRATE=2400.PARITY=N.DATABITS=8",UPDATE,DISPLAY,VARIABLE 1 but nobody does that. Just for fun 10 OPEN #1:"RS232.BANANA=2400.PARTY=N.DANCE=8",UPDATE

How it works The top 3 bits of the address are decoded into 8 enable lines by a 74LS138 decoder. Not all of these are needed, but the one that corresponds to A0,A1,A2 equal to 0,1,1 or addresses >6000 to >7fff is labeled ROMS* or cartridge select. This goes to the module port, where it is connected to a CE1* or chip enable pin on the cartridge ROM. The effect is that the cartridge ROM only 'wakes up' when one of those addresses is present on the address bus. The rest of the address lines A3-A15 go into the ROM or RAM chip to select a byte. In a similar way, the line responding to 0,0,0 goes to the CS* on and activates the console ROMs (16 bits wide). The line for 1,0,0 goes to yet another 74LS138 chip enable which decodes A3,A4,A5 to subdivide the >8000 - >9fff space into 8 blocks.

See: http://atariage.com/forums/topic/261650-nanopeb-v1-rs232 LI R12,>1300 SBO 0 page in the dsr rom * example. do your port 1 serial stuff now as usual LI R12,>1340 TB 3 LI R12,>1300 SBZ 0 page out the dsr rom It is still >1300 right? Other points from that thread summarized: v1 with a 9902: requires the DSR to be paged in during RS232 operations by setting bit 0 at >1300. TI RS232 doesn't need it. v2 with a 16550: these only have a COM device in the DSR. I agree with Greg - unless you only have the v2 right now... just ignore them. I think I have a v2.

I am not up to speed with TI GCC yet (I only followed it for the shift left / shift right bug fix, that bit you hard too). Access to the DSR ROM is a DSRLNK call with a PAB structure. Essentially the code can be the same as disk access via DSRLNK, just with "RS232.BA=2400.DA=8.PA=N" instead of "DSK1.SOMEFILE". Other than that, read/write flags and record parameters work according to TI's standard DSR behavior. Which was the good side of the whole DSR specification. But calling the DSR is going to get you only so far. A bunch of us (myself included) started BBS software using BASIC to call the DSR and as soon as possible went to direct assembly access to the 9902 for character i.o. On the input side, a DSR call will block, waiting for N characters or a carriage return, then miss chars between calls. The output direction should be ok. (In my opinion, TI fixed all the problems with their DSR spec in the 1983 HexBus RS232 peripheral and it was usable from Basic. I found it quite versatile on the CC-40 Enhanced Basic with just OPEN, LINPUT and PRINT and I guess we would have seen some kid write a whole BBS in Extended Basic II on the 99/8, if TI had not killed it.) I am game for locating the 16550 character i/o routines in the NanoPEB ROM, if Fred Kaal did not already reverse engineer them.

It looks like the programs assume that E/A has set up things in the VDP. In particular, the char defs (with a © character that's not from the console char defs), color table, screen color in VDP register 7. In the case of D-station, it looks like an extra sprite, so that game may assume E/A has put sensible starting values in the sprite table. Its possible that Fweb cassette loader tries to set up the VDP to match the E/A environment (it gets the color), and leaves some differences.

Like converting the Line by line assembler to EA3 or EA5? Its one thing to read in in whatever file format Easy Bug writes out, but it has addresses based at >7000. Fine if you have an E/A with 8K RAM installed. If you want that to load into the 32k, thats a hard problem. Rebasing code means figuring out what is an address and what is data. You can do a quick and dirty job and wind up with errors.

My 6502 is pretty poor, but I read the original code as finding 3x the 16 bit value then shifting 3 times to divide by 8. You can't do a 3/80 with just a few adds and bit shifts.

OK, badwalls may rely on something particular to E/A default setup, or load something somewhere (low memory) that Supersave can't detect. I am happy to go in there and see what it is.

Here's one way * R1: input value, -32768 to 32767 (signed) * R2: output is R1 * 3/8 mov r1,r2 sra r2,1 shift right arithmetic (signed divide by 2) a r1,r2 sum is 1.5 times r1, sra r2,2 now divide by 4 (signed) I'm not familiar with the C calling conventions, maybe you can patch that into your code. (awesome progress on PLATOterm by the way!)

I'm happy that this worked for you. I can take a look at the games that didn't convert to see what's up there. Are those the versions from Gamebase or somewhere? Maybe a new version of Supersave is in order... Just now, my desk holds only a cassette based 4A (lots of Mini Memory and LLBA from cassette, I mean WAV file), so I may have a go at the Funlweb cassette loader. Separate thread for Supersave: http://atariage.com/forums/topic/287103-supersave-save-ea3-files-as-ea5-files/

Hi! I'm glad another person remembers my program. Yep, Supersave does nothing specifically to help with XB loadable object code (except purely relocatable code.) I wonder if you have the whole disk image? It had other things like my brother's game CRASH that I have lost. It is mysterious to me where the master copy went to. One of my disks had an archive of Archiver 2.0, which came with a separate Squeeze program and a note about plans for Archiver 3.0. I think that explains my unreadable (in 3.0) archives. For Extended Basic object code, loading to low ram, Barry Boone's SYSTEX was ideal. Systex moved the low ram into the high ram inside the XB program table, added some glue to move it back to low ram at runtime, then you save the whole program as one unit. This gives you a very fast load time for assembly code, compared to the XB CALL LOAD. I used Systex when TI-NET BBS assembly code filled all of low ram and took quite a while to load. I peeked into what Systex did and used that technique for Bubble Plane to mix assembly with XB in one file. When Bubble Plane loaded, only the title screen and high score file management was in XB, while the entire game ran in assembly in high ram. Merging the object code into the final image was tricky, and editing the Basic afterward was hazardous. The development process had gone from 100% XB, trying and giving up on the Basic Compiler of the day (Exceltec warned me that it wouldn't work out), to XB with A/L support for scrolling the screen, (writing the map editor using the same toolbox), to all assembly for gameplay. This version shipped on floppy. Finally I got it into a 8k cartridge image plus 24k of RLE compressed data, and used GPL on the Geneve to simulate bank switching by paging at >6000 to get at the data. I didn't know who could publish it though. Footnote: I wrote Supersave one day when I was frustrated at all the steps needed to load and run Congo Bongo (the leaked beta on disk was a dozen or more object files.) Unfortunately, Supersave didn't get everything right and the image would not run after a cold restart. It's also true that I was perpetually out of floppy disks and needed to save space by compressing games.

That was a great story. Thanks for sharing.

This is the source to a utility I wrote in 1986. You load SUPERSAVE before other object files, and it tracks the free addresses in high RAM. It works on relocatable EA3 object files, and supplies its own copy of the E/A utilities. Supersave itself loads into low RAM (>2C00). supersave.txt Before you load other files, Supersave puts a B instruction at >A000, followed by a version of the E/A utilities. You have the option to include none, or KSCAN-VMBW, DSRLNK and so on. Supersave intercepts auto-starting object files by patching the E/A Loader. I'm sure there are some cases it doesn't handle, including code with AORG. I wasn't able to find the disk I distributed this on, so there is no documentation or other goodies that I distributed on the fairware disk. The source code was in an ARK that was unreadable by Barry Boone's 1988 or 1989 Archiver 3.03 versions. Anyhow Fred Kaal's TIDIR unpacked the archives ok into this PC text file. SUPER.BIN is a TIFILES object code that I just made, fresh out of the Funlweb 4.10 assembler, in Classic99, but I expect all bits are identical to the original. I'm not sure what to name an attached executable but AtariAge seems to like .BIN. It's a DIS/FIX80 EA3 loadable file with a TIFILES header. SUPER.BIN And to test that it's working, I converted a standalone speech demo from EA3 to EA5. Attached also in TIFILES format please find TALK1.BIN TALK1.BIN