jedimatt42

The error would indicate that there was a line that did not have an "=" in it. A blank line would cause this. PI.CONFIG is probably very intolerant. I can improve that a bit, such as ignoring any line that isn't of the form: key=value

Libti99 has a GPU routine for scrolling extended attribute text, which works with its conio routines as well. You can compare performance, and cherry pick what you want out of there... I think it is defined in the routine for setting up 80 column color text mode.

Floppy disks on the TI don't generally support subdirectories... but ForceCommand supports all those harddrive type things including TIPI. The Myarc hard drive extensions gave us directories, where there is a LVL2 IO routine to set the unit #'s directory before performing unit # based operations, since all of those original TI LVL2 routines just take a 10 character file name... There are additional routines for creating, and removing a directory. Anyway... I sent you a private message with an alpha of ForceCommand that will support treating 'DSK.' as a drive. I can't really support this on TIPI, cause 'TIPI' is unit 0. It makes all kinds of things ambiguous... I might follow up with making sure ForceCommand disallows 'DSK.' if it has already seen 'TIPI.', otherwise direct-input and direct-output operations on TIPI would get very confused.

@JasonACT, we are dealing with really old software that never thought new hardware would ever come into existence. Rich Extended Basic won't be alone. We know that The Missing Link / TML, will also choke if the 'floppy disk controller' hasn't performed the equivalent of CALL FILES(3) during the powerup entry in the DSR ROM. After much discussion previously, and then again when I came around with TIPI, the consensus was, even though your storage device doesn't need sector buffers in VDP, it is wise to let the default state reserve those buffers. Here is the part in my TIPI powerup routine that handles this: https://github.com/jedimatt42/tipi/blob/51855d04633b834f278da938a0ec9a8da753a813/hardware/dsr/powerup.a99#L27 - you'll notice, I only do this if running at crubase 1100, as I'm responsible for being the floppy controller. This code isn't ideal either, as I don't read the current value, and then subtract what I want, instead I just slam 5 bytes int there. I no longer remember why... Why? : - If we don't do this, people may unwittingly produce disk software in XB using your device that is too large to load into someone's XB using a real Floppy Controller, unknowingly... - Old software made assumptions, and users will pester you about it if it doesn't work. - The BASICs have additional work area associated to each sector buffer, handled by the CALL FILES... But, 1st and foremost, it is your hobby time... There is always going to be something that isn't compatible, 'cause old assumptive software is out there. Note, this is just a suggestion that would likely work around the problem and others. Since RXB is actively developed, another solution might be for Rich to update RXB to initialize the VDP stack in a compatible way by default...

The "DSK." device name was never used for LVL2 type IO, but ForceCommand just has a condition block to handle unusual device names and unit numbers.. I am open to extending ForceCommand to understand your device. It currently has a strong opinion about what a drive device name is. I can work up a beta for you to test. ForceCommand won't let you 'cd' to a place that cannot be opened as a Catalog File. That really bothered me in the old 4ADos. So you wouldn't be able to CD to "DSK." on a normal TI Floppy Controller. But I believe you can CD to "DSK.VOL1." if it exists. Also, the drive that ForceCommand 'boots' from ( looks for AUTOCMD script on ) is the first device in the DSR list, so if you want that to be "DSK.", it should be first in your list. If you want that to be "DSK1." then that should be first.

https://github.com/jedimatt42/tipi/wiki/PI.CONFIG#native-text-directories I thought the BASIC example for adding a dir to the list provided unambiguous detail.

TIPI on Libre Computer Le Potato: It's been a while, but I've got an SD Card image prepared for the Le Potato. It is experimental. https://jedimatt42.com/dl#experimental Things to note: - Le Potato does not have a WiFi, so you have to use ethernet, or a USB WiFi 'nub' - I don't think it 'halts' on shutdown... And shutdown/restart takes a while - I will probably have to put some creative effort into improving this. - If a keyboard is attached ( I haven't tested mouse yet ) then boot takes quite a while. Without keyboard attached it moves along fine. - My experience, and Libre Computer literature suggests, you need high speed Micro SD card. I've used U3 rated SanDisk. The image is 32GB as that is the smallest U3 SanDisk I could buy at the time. The download is still just over 1GB cause blank space compresses nicely. If anyone gives this a shot, understand that it is experimental. It seems to work, but I haven't tested every corner.

Skipping the XMLLNK like address lookups would save instructions and reduce calling overhead. If you document which console ROM addresses you use as entry points, then any alternative console ROMs (a practical myth) could still support it.

This is fixed now in a newly uploaded SD Card image. I also freshened up SD image with current 3.17 code.

I'd love to renew my subscription, but before I can enter any payment information, I just get an error. Press Place Order and Pay...

There is a bug in TIPI 3.x SD card image the prevents the tipi_kernel_module from loading on Raspberry PI Zero W ( and probably plain Zero ) I've produced a fix, but don't have time at the moment to fix the SD card image and re-publish it. So, manual steps to get going if you are in that situation for the time being: - ssh to tipi@tipi.local or attach a keyboard and monitor and login as tipi user - cd to /home/tipi/tipi_kernel_module - run : git pull - run : sudo reboot now on boot it should then automatically recompile the kernel module and load. It was supposed to do this, but a bug snuck in, cause I tested that on a different brand of SBC originally. Hopefully I'll have time Friday or Saturday to update the SD card image, so this can be forgotten about.

Extended BASIC and EA both will place the DSRLNK assembly access routine in lower expansion RAM. If you are linking to that routine, you will have to include your own copy in the ROM. There is an implementation in libti99. I borrowed and modified that for my needs with ForceCommand which is a cartridge ROM. I am confident I did not need to mod libti99's DSRLNK until I wanted to precache all the cards DSR addresses. https://github.com/tursilion/libti99/blob/189cb667a2b8753cc1d5e399d3355a9cbc9c7a09/files.h#L88

Community is built through contribution. If you all don't start the conversation you want to have, you all will never find the others that want the same conversation. --- As for holy grail, I would think that would be as individualized as the people here. From what I can tell, most of us have very different hobbies. They just share some little piece of the 4A platform. My holy grail is the computer I haven't designed yet.

You can do the equivalent of pressing FCTN-U in the TIPICFG tool by using PI.UPGRADE : https://github.com/jedimatt42/tipi/wiki/PI.UPGRADE When TIPICFG perceives a new version and you press the offered 'U' option, the above is what happens. However, you may just upgrade to the version you currently have if your network location or PI doesn't see the changes on github.com. So if TIPICFG isn't offering an update, you probably have other problems. Or I failed to push to github again... github looks up to date: https://github.com/jedimatt42/tipi/blob/bullseye_release/version.txt

For what possible reason would you need that?

Update 3.17 Squash Unicode characters when sending strings back to the 4A using the JSON query file support ?J flag. Processes the string data with this library: https://pypi.org/project/Unidecode/ If this ever proves to be not desired (I don't care about theoretical issues, but practical issues because a piece of software being written needs it), let me know, and I'll make the squashing able to be disabled

I believe FFFE is the address of the non-maskable interrupt vector, probably not always triggered on power up, not sure. Then reset should occur, and 0000 should be read for setting the initial WS register. Which would set it to 83E0, address of R0. Then the accesses to 83FE, a.k.a. R15, and 83FA, a.k.a. R13 is likely reset initialization, before the first instruction has been read. Then access to 0002 loads the PC with address 0012, the location of the first instruction. ... @Tursi, seems like he should be able to follow the disassembly from the classic99 4 emulation mode, but Sunday, I couldn't get it to breakpoint on these early accesses...

The VDP is only attached to 8 of the bits on the data bus, so it isn't as better as it might be without a new motherboard. Then there would be other tradeoffs. From routines to write text, to changing the screen color... It would be hard to tell if was a win-win without redesigning the 4A.

The flags in the PAB might be important. I would expect it (PIO) must be sequential, and I would try starting with output mode.

The beep is a bug. I thought I fixed a while ago, but I guess I missed something. Placing tipibeeps in the AUTOCMD script likely works around the issue. I'll have to reinvestgate. There is an editor built into ForceCommand, try 'help ed' and from within ED, try FCTN-7 (AID) Apparently I forgot to add ED to the wiki documentation. Oops. (update: added ED to wiki: https://github.com/jedimatt42/fcmd/wiki/Commands#editor)

I've used this with a Corcomp floppy controller, but not with the Corcomp eproms... The 'auto' cartridge menu item run the GROM powerup routine to launch into the cartridge rom. Sounds like there are some conflicts with the Corcomp powerup routine and my cartridge powerup routine. ForceCommand is fully functional without the GROM, as it only provides that powerup routine to auto-run the cartridge ROM. Be careful renaming binaries on the FinalGROM99 SD card. The filename is used to determine the emulation type for the file. Instead of renaming my files, I create list scripts in a directory on my PATH that I can run to go to the desired cartridge. Then I can name the script whatever makes more sense to me. The other thing, the binaries in TIPI.FC.BIN. are ForceCommand executables. The LOAD command is for EA5 PROGRAMS. To run a ForceCommand executable or script, Just enter the filename, or directory and filename if it isn't on your path or in the current directory.

I think this is mission accomplished. There are now at least 5, easy to use sideport 32k (or greater) expansions, generally available, with multiple vendors.

It is not horribly outside the realm of possibility to extend ForceCommand to 'also' output to speech. Somewhere around is a library of assembly code that implements the Text to Speech algorithm used by, or similar to, the Terminal Emulator II cartridge. It would be enjoyable to incorporate that into ForceCommand. All of the screen output in ForceCommand is funneled through a few terminal output functions. This is so that someday I could hook in there, and build output capture. I think early MS-DOS had CTRL PrintScreen or CTRL P keys you could press to toggle duplicating output to a printer.

ForceCommand does not have support for output redirection like in MS DOS or other shells, not even to a printer or a file. The vocabulary in the speech synthesizer is pretty limited. XB simply exposes that vocabulary. My 'SAY' program is not a speech synthesis program as much as an audio file player, it just plays LPC encoded audio files designed for the TI's speech synthesis chip.

Both my Corcomp Disk Controller and Texas Instruments Disk Controller have a keyed IDC ribbon cable connector, in the same orientation. And the TI controller labels in the copper layer that pin 2 is at the bottom and pin 34 is at the top. The edge connectors parallels the IDC connectors. So I assume for either, pin 1 is at the bottom.