jedimatt42

Sunday this week... 3pm pacific.

TIPI is a highly extensible bit of code, and people are free to extend it, but to be clear, I will reject PR's around pure computation. However, the instructions for installing on a fresh Raspbian are there. Anyone can take up distributing a fork. I have purposely licensed away my right to stop anything. ---- I really like the idea of loading up the F18A with 9900 assembly to do computational tasks. Even that probably has a bit of a barrier/cost. For IPC, you have to use mailboxes in VDP ram. I'm not sure how you know when the work in complete, except to keep it faster than you can ask. Someone could probably design a real nice software package to load in that has a little bytecode language and establishes a set of VDP RAM addresses that act as mailboxes to receive commands, and hold accumulated results. Issue one or more commands, then fetch results. Although, I really admire the 8 bit programmers that figure out how to solve the problem without even a multiply and divide instruction in their 6502s.

I'm saying I'm not interested enough to think about math over messaging at all.

People have asked about general computation facilities on the PI, and I have rejected that as crossing a line I am not interested in supporting. What I think would be cool, is actual integration of an early 80s floating point coprocessor. There were general purpose FPUs not targeted to specific CPUs.

I couldn't read Beery's post. It was all green and hurt my eyes. Still does. But given InsaneMultitasker's summary, sounds like I should error on write, if no open occurred. Surely just an oversight. Error handling isn't necessary if no one else writes a bug. LOL.

Depends, the best I could tell, is there were multiple techniques to bring an interrupt signal back into the console, such as over the EXT-INT.

The sticky thing here, is there is no emulation that supports TIPI, and the 9938, to my knowledge. So without real hardware, we can only guess... Since the graphics show up from the built splash or whatever you want to call it... I'd say the screen output isn't an issue. I had another program that didn't work correctly on @wolhess EVPC, when using the cru based VDP interrupt polling: From line 96 in libti99:vdp.h #define VDP_WAIT_VBLANK_CRU __asm__( "clr r12\n\ttb 2\n\tjeq -4\n\tmovb @>8802,r12" : : : "r12" ); So the use of this in https://github.com/tschak909/platoterm99/blob/3451c9bf9764ed9f4f51e9ad03bb93354651a201/src/main.c#L25 is blocking forever.

On initial examination, CHATTI, CHESS and SNEK are getting errors from the server. So it looks like it is not a TIPI problem.

Maybe something changed in a 3rd party dependency...

Think of it as printing to a FILE, not a simulation of the PIO device.

CHESS and CHATTI are probably leftover breakage from the python3 conversion. SNEK was reported, and I was able to fix it. I don't have access to the server or client code, just the TIPI piece in the middle. I will try and fix it this week. I don't run any of these programs unless someone reports an issue. The black blocks might be an error in the way EA5 CHESS loads the character set over the internet. Platoterm, my guess would be that it suffers from the same alternative VDP interrupt issue that Force Command demonstrated. In force command I fixed it by giving up a feature. My TELNET client is poorly labelled... it shouldn't say "80 column", it should say "F18A Full Color 80 column". That mode will not work on the 9938. I have no intention of fixing it to do so. I have some intention of re-writing a new telnet based on Force Command, where I've already abstracted the terminal display out. But this is lower priority than my current project.

COPY CON AUTOEXEC TIMODE <CTRL-D> Or the actual MDOS equivalent. You can of course also just COPY AUTOEXEC ASIDE and reboot. You won't find a computer I've used for more than a moment without the filename 'aside' showing up.

Actually that having been voted down seems ridiculous... I suspect the 99/8 is closer to a 4/A than the Geneve, at least as of when the Geneve was released. Yet 99/8 talk is relegated to the tomy tutor sub-forum.

Hasn't that been repeatedly voted down?

I like Mizapf's "You're holding it wrong" response.. I like any opportunity I can to interject that people should look at the PI in a 4A/Geneve setup with a TIPI as no different than how there is a microprocessor in a C64 and Atari-8bit floppy drive. The TIPI board itself is no different than a 4A's RS232 board, or the SIO port on an Atari-8bit..

Unless it is widely used, I'd recommend removing that feature.

I guess I should add error checking to the mapping code for TIPI so you get feedback that you've entered an invalid mapping. TIPI mapping cannot target a disk image, it can only target a directory on the TIPI drive. When you put a valid disk image of files for the 4A on the TIPI, it automatically converts it to a directory of TIFILES FIADs. I don't think this is possible for P-Code. I highly doubt P-Code uses LVL3 or LVL2 IO routines for 'file' access. I recall hearing P-Code used it's own floppy format... so I assume it needs LVL1 (read-write any sector) access. TIPI doesn't have LVL1 access, there are no sectors on a TIPI. TIPI does support LVL2 file block IO... but that's a different thing... I have it on good authority that the developer of TIPI doesn't own a P-Code system so he's not likely to ever support it.

As there are 2 version of a 1.00 boot rom already out, why would you call this 0.99? How will people know that is newer than 1.00 ?

CALL TIPI("PI.HTTP://ftp.whtech.com/TIPI/DM2K") You can conveniently load programs right off the internet... (if your PI network works)

I expect nobody has tested with MDOS 6.00 and the corresponding GPL. If that version of GPL supports ROMPAGE, then you should be able to use E/A option 5 to load "TIPI.TIPICFG" in GPL/ROMPAGE -- if this works, then you can load better copy tools from the TIPI... MDM isn't going to know about TIPI, but the latest DM2K should be able to work with 1200.DSK0. as the source TIPI drive, and then you can copy from the TIPI to your MDOS friendly storage such as 1100.DSK1. At least that would be the theory... Anyone know if ROMPAGE works in MDOS 6.00?

Isn't it CTRL-SHIFT-SHIFT to get back to the GPL speed/cartridge/mode selection screen... and another CTRL-SHIFT-SHIFT from there to go back to MDOS.. ???

There are TOO many ways you can do this to prescribe one. So... I would use NFS. You could delete the /home/tipi/tipi_disk folder on the subordinate PIs. On the primary PI, you can create an NFS export for /home/tipi/tipi_disk, and then back on the subordinate PIs MOUNT the NFS share to /home/tipi/tipi_disk. You could probably also just mount the existing SMB share from the primary on each of the subordinate PIs. Or, you could require that your PC be running when you use your TI, and mount a share from windows... You could also mount below /home/tipi/tipi_disk like in a 'COMMON' folder ( so TIPI.COMMON. becomes the distributed folder ) This isn't really a one-size-fits-all situation, but you have a full network friendly operating system in linux to enable this in dozens of different ways. Maybe one of the fine network-admin types on this forum would like to write up a howto-guide for people that don't linux. I personally haven't found the need, as when I develop, if I want the binaries distributed to multiple PIs, I just script multiple SCP commands from my desktop as part of my build script, pushing to each PI. But I only have one system with a TIPI running now. I use NFS to share between desktop and emulated PI, and in that case the mount command on the PI looks something like: mount -t nfs ${HOSTIP}:/tipi_disk /home/tipi/tipi_disk This assumes the 'export' name from the NFS server is 'tipi_disk' and the address of that server is in HOSTIP variable ( that can be replaced with something literal ) I haven't ever tried to export NFS from linux myself... But the raspberry pi org has documentation: https://www.raspberrypi.org/documentation/configuration/nfs.md

I re-uploaded the zip... somehow I didn't get 1.17 into the 1.17 zip...

For some deranged reason I just made this:

Update 1.17 - small change to ED editor, when in insert mode, pressing enter should move whatever is after your cursor down to a new line, shifting all lines below down a line. However the last line was being lost. 1.17 fixes that.