jedimatt42

I believe I have 2 confirmed installations (besides myself) of the updated EPROM.

@dgrissom there should not be any magic associated to the eprom update. Maybe the hardware is just unsettled?

I thought about CS2 a little, but dismissed it pretty quickly when I took this on. For posterity, if CS2 ever becomes valuable, this is the python side code change: https://github.com/jedimatt42/tipi/commit/883f2f6967f3baed6fca9a3d7c20e022ebd84f67 and this is the DSR ROM code change: https://github.com/jedimatt42/tipi/commit/ab33a63096c382f75fd2f800e5e8e0bb95b18a42 <- I called it 'TAP' when I thought I couldn't override CS1, but then I read a little console ROM DSRLNK code: https://github.com/jedimatt42/tipi/commit/8d5cf9c8726e18b626919340d17334535e2d6509 Todo: I already need to restructure TIPICFG to handle DSK5-9. They aren't included in that tool at this time. They can be set via writes to PI.CONFIG or the web-ui. But I think I need to break the mappings to sub-screens. ForceCommand needs an update to it's TIPIMAP command for controlling them as well.

I can see the use case for CS1, but I don't see it for CS2... And I put my PEB back together already... Is there a program already written that has less function due to not having CS2?

Here is one of my preliminary post in the dev thread with some of the background :

Update 3.20 - 2023-08-04 - Added CS1 & DSK5-9 support in PI.CONFIG, and web-ui - Added CS1 support in TIPICFG - Added CS1 & DSK5-9 support in DSR ROM ( The physical eprom on the TIPI board ) - Updated the ea5 loader in the ROM used by CALL TIPI to leave more of scratchpad intact. Fixes loading the last couple years worth of DM2K from CALL TIPI. Functionality degrades gracefully... DSK5-9 and CS1 mapping are not effective without the ROM update. The CALL TIPI ea5 loading fix is in the ROM. You can run version 3.20 of the PI software suite without the ROM update, you just won't get any benefit. Using TIPI as CS1 is deceptively fast... there is no prompting to rewind/press play/etc... the PAB operation just performs. If you want to actual cassette driver in GROM to be used, then clear your mapping for CS1_FILE and TIPI will allow the console DSRLNK to continue searching until it finds the GROM driver. (Even if it is useless to you, I can only justify supporting, for free, the latest version of the software.)

Plowing ahead.

What kind of trouble would I cause if I added DSK5-9? Would it create coexistence issues with an HRD?

So, @jrhodes asked if it was possible for TIPI to act as the cassette storage device as well. I always assumed due to some mis-reading of the console rom, that the GROM DSRs were looked at first, and then the expansion card ROMs... but that isn't true. The console DSRLNK does go to expansion cards first, and then falls back on the GROM list. So, it is totally possible with a small change to the TIPI DSR ROM to include a device name for CS1, that the TIPI can service the PAB request first. And the TIPI can reject the request if not configured for it, return the to DSRLNK to resume scanning for other devices that might service CS1 and the real GROM CS1 device will be found and allowed to continue. Just like when DSK1 directories are not mapped... There is at least one program that only supports CS1. Milton Bradley's Hangman. My implementation just delegates to TIPI's handling of a file in the TIPI. filesystem. All the weird things like loading Tidbit source as a BASIC Program Image file works for CS1 if that's what you map it to. There will be no prompts to rewind I've added a setting in PI.CONFIG - CS1_FILE which should be set to the file name you want CS1 to read or write to. If it is empty, then no mapping is made, and the GROM DSR will kick in. I've updated TIPICFG so you can set this from the 4A easily. I have also updated the TIPI Web UI. There are some screen shots below. I'd be interested if anyone has a more intuitive recommendation for managing this. Maybe I'll through the word 'file' in there a few times to make it more clear it's not the same as all the DSK dir mappings. Feedback, and other thoughts are welcome. (Use of this feature will require a TIPI ROM upgrade, and TIPI services upgrade. TIPI services upgrade will not require the ROM upgrade, but the CS1 feature will simply not work.) --------- Here if CS1 is unmapped, you'll see a text box next to it so you can set the CS1_FILE mapping to whatever name or path you want. This should be a TI type path with '.' for directory separators, etc... and it should represent a file, not just a directory like the other mappings. Enter something, hit 'save' and your next interactions with CS1 will create or use that file. Alternatively you may navigate to a file in the TIPI filesystem, select it, and then use the Action dropdown to choose 'Map to CS1', and submit... When it is set, you'll see the value. To unset the mapping, just click the red X next to it.

thanks for pointing out this section of the EA manual. After reviewing it, my stab in the dark at clearing all of scratchpad from 8300 -> the workspace used by the console interrupt routine, is clearly too aggressive. Seems like I should stop clearing at 834A, where pretty much everything beyond may have some value to a console routine, that some legacy program may depend on. I'll make a relevant change. -- what I'm really tempted to do is snapshot that memory in a little program loaded from EA5, and then restore that from the ROM before launching programs. I've got some 26k free... I'm playing around with another request that may require a ROM change, which is a better value add for anyone sourcing the DSR rom upgrade.

Thanks, It is a trade off... There are other programs that will fail if their workspaces are not pre-zeroed... Most assembly programs don't expect scratchpad to look like it came from BASIC. What does the value 0x9E7E at address 0x8372 represent? And what program cared?

The one labelled Xilinx

Sadly, I've never seen a survival... the CPLD pin that get mis-connected, dump the full current the PI's 5V supply can provide before it cooks, in an instant. I've replaced the CPLD on half a dozen of these, and that has always resurrected them. I don't have any spare CPLDs anymore, so I'm not in a position to offer repair service.

Most software does not access a specific drive. It accesses a named device. The system then visits the devices ( in order of CRU base address ), paging in their respective driver ROM that holds the Device Service Routine (DSR) associated to each device name. TIPI's ROM has a DSR associated to DSK1 (and the others ) so that it can handle mapping directories to the floppy device names. The mapping configuration is on the PI. When you access DSK1, the TI sends the request to the PI, and this blocks in a loop waiting for the PI to consume the message. If the PI responds with a 'not handled' message ( loosely speaking ) then the TIPI DSR returns to the visiting routine ( typically called DSRLNK ) which usually then continues visiting the next device. This facility was a stroke of genius by TI engineering. If you want to run the TIPI board but not have the PI operational, you can connect a switch to the top CRU base address jumper blocks. This would allow toggling the TIPI CRU base address high bit on or off, shifting it to well after the standard floppy disk controller when the ROMs are being visited. "TIPI.", "DSK0." and if using a TI disk controller, then TIPI's "DSK4." will still be accessible (if the PI is on) to most TI software. TI's floppy controller does not report 'not handled' to DSRLNK, so DSRLNK will not continue to search for the overlapping device name. The floppy controller CRU base is 0x1100. The TIPI CRU base in your configuration should be 0x1000, and with the switch closed, 0x1800. I think most 99ers never had a hardware configuration where they needed to know this forward thinking, powerful feature exists.

It alternates every weekend between the Saturday time and the Sunday time. The schedule was influenced by public vote. I had other preferences myself, but chose from the top voted slots. I would be open to reassessing what works for people, including a third EU schedule.

4A PABs don't talk much about actual file size in bytes... except for PROGRAM LOAD / SAVE. But here, you must have already changed the TIPI DSR for LOAD and SAVE as my implementation only works off of buffers in VDP. Implementing this in terms of whatever front you have for Direct-Input and Direct-Output But if you want to keep to the LOAD and SAVE opcodes.. I could fix the TIPI python side to understand a 3rd byte... If I where to guess, you probably send the high byte in byte 5 of the PAB just before bytes 6/7, the normal number of bytes to save/load... ( edit: Oh, but the single message size limit for TIPI is also 64k ) The only issue I'd have, is if 4A software has any history of dirty PABs that have junk left in byte 5 ( or whichever one you expect it to be... )... Is there any other bit set that indicates the extended mode for the PAB? --- My direct-write can only write 64k at a time, but it can have a starting block address anywhere in a 16Meg file. So you could delegate to that as is, in 3 TIPI operations.

Sunday the 16th, at 3pm Pacific, 6pm Eastern. Saturday the 22nd, at 11am Pacific, 2pm Eastern. I'm going to be absent, this weekend and next (those two above), but the Zoom is there even if I'm not there to host. If you are new or just stayed away because I'm always there, and want the password to join in, you can PM me, or @arcadeshopper and we'll get you the password. If you just join for my smile, then it and I will be back for the following series. Enjoy, -M@

The posted update should fix your TIPI issue.

A fix has been posted.

Update 3.19 - July 14th 2023 More bug finding love from @InsaneMultitasker, @dhe, and @9640News - Fix native flags so that when creating a file (OPEN OUTPUT or APPEND when file is not present) if a native_flag is set, then the PAB data type and record type and record length must be appropriate for the active native_flag. * Note: internally NATIVE_TEXT_DIRS sets the ?W native flag for operations, so this should fix the create of DF80 object files in the Geneve MDOS source builds where the source or build is happening from a directory specified in NATIVE_TEXT_DIRS. ** Note: This restricted ?X native flag to DISPLAY FIXED 128 files.

None of the switch terminals are to ground. This is opening (off) and closing (on) (when in the pushed in position) the 2 AC leads from the actual rear power plug. White has continuity to white only when closed, red has continuity to red only when closed. White connects from the power socket, through the switch, and into the transformer. If I recall correctly, red connects from the power socket, through the switch, through the external fuse socket, and then into the transformer. The switch never closes white and red to each other. Ground is connected from the power jack 3rd prong to the chassis. It never touches the switch.

My Gemini browser uses SAMS. ForceCommand applications can use SAMS, or be stacked in SAMS, if you write to the ForceCommand API. An example is FCMENU.

The only thing that makes sense is that only DiS/VAR 80 files are headerless in a native folder. Any other file type should be treated as a TIFILES file. That is the intent. Sounds like I got it mostly correct for direct-input and direct-output, but missed a bunch of test cases for record access. I will fix. But I have a busy week, so I probably won't get to start into it until Saturday.

The intent is that saving a DIS/FIX or PROGRAM to a native text folder would produce normal TIFILES headered files.

Update 3.18 - July 9th 2023 Bug fixes brought to my attention thanks to @InsaneMultitasker, and @dhe - Fix PI.CONFIG write operations to ignore lines that are not a map entry - Fix loading of /home/tipi/tipi.config to also ignore lines that are not a map entry, in case you manually edit it from linux. - Fix web-ui to show perceived file type based on NATIVE_TEXT_DIRS configuration.