jedimatt42

Those emulation conditionals have nothing to do with running the current TIPI emulation with js99er. Forgot they even existed... Now that we have js99er integration, I should remove the debris in the DSR completely. It was for mocking responses when stepping through the DSR code in classic99. --- SPI? That wasn't intentional. But yes it is really close to SPI where the PI is the master, and I do slave-select oddly. I probably could have saved months if I had read the SPI specification.

The serial communication magic is described here. https://github.com/jedimatt42/tipi/wiki/TIPI-Protocol Being 100% agnostic to the speed of the 4A CPU and the PI is a cornerstone of the design.

In TI BASIC it scans Device ROMs for subprograms with every CALL before looking for built-ins. In XB, it is useless (exaggerating (tm)) as Device ROMs are only scanned in immediate mode.

I wouldn't call that finished.

Usually after I ask a question, I think of better search terms... answered here:

All the bullet lists indicate there is a realtime clock... I'm an Atari 8bit newb... is there a standard for the clock that the side3 follows? The built in Spartdos X DATE and TIME commands don't seem to do anything.

Sorry I had to drop today without saying anything, but there was some technical difficulty, and zoom didn't have my mic. I think nobody could hear me for a good hour of the conversation before I realized it was most likely something technical.

I use this macro assembler: https://endlos99.github.io/xdt99/#xas99

Thanks, yes, with both connector types populated on the pcb, but only one in use at a time. That's perfect. I would definitively support this with a purchase. I was afraid looking at the pcb layout that it was a choice that had to be made at the time of assembly.

Updated - 1.4 should fix @klrw111-78 issue. I dug out some computer science data structures courses I never took, and implemented a global system dictionary, and a heap. This is all internal, but the benefit, is removing artificial caps on device names, and environment variables. I should apply it to the LABELs in scripts too. < 1.0, I allowed something like 40 pre-allocated slots in .bss for device entries that I pre-fetch. An un-TI like thing I do to make generic storage easier for me. in 1.0, I asked myself, who in their right mind would have more than 20 drives? that seemed like a lot of ramdisk space, and plenty of hard drive and TIPI mappings, etc... But it turns out someone actually has it all. I also had pre-allocated ~90 bytes per environment variable slot, with slots allocated for 20 variables. All of this is linked into the system in the block storage section. So, in 1.4, I've added heap, so I can dynamically track allocation after .data and .bss (all the statically allocated junk) fill the bottom of lower memory expansion. Then I initialize all the things that need to be on heap. Right now that is the device index. Then I treat the top of that as the global system dictionary. The c stack is at the top of lower expansion memory and grows down. This dictionary is growing up from approximately 2k from the bottom (depends on the number of devices). The dictionary entries have a type byte, so I can move the script LABEL system into it as well without name collision. The dictionary compacts if you replace or remove an item. Quite satisfying.

Are the hexbus and dockbus ports free of physical coincidence? Can I use it on my CC-40 then move it to the 74? or is it choose one, and adapt for the other via a cable?

It's pretty cool technically.. I don't think I've seen any other software on the 4A play music while loading records from disk. Entertaining you while loading was a big step in home computer gaming from disk.

I would expect if one of the bus driver's is gone bad from your 6V adventure, that the impedance, while maybe not a full short would be very different from the good ones. Depends on how hard it is to probe... You should be able to measure outlier impedance with the board off, outside the box. So that while tedious and time consuming might point at a single chip to fix. If you are good with the ChipQuick and hot-air, then I would think removing one at a time until it livens up would be a winning strategy. If one is bad, then you'll have to anyway. You know it works when they are not connected. I think I'd start (if they are clustered just right) with chips handling control signals, and save address or data lines for last. Addresses are outputs, and a cpu should still cycle on bad instructions from bad data. The other thing you could do is reproduce the symptom outside the bus backplane... connect a pull-down resister to ground, and probe each of the bus outputs or inputs to see that they respond properly ( no effect, or desired effect if it is something like a wait state or reset line ) Just shooting in the dark.

I bet I know what I did... I think I decreased the number of drives I have crubase indexes for. I can fix that.

It has to be split, or it will be useless. Don't glue it together prior to inserting the PCB... notice the grooves... the pcb goes there. I split mine square close to natural locations, for the Ender 3 when I printed it... there was probably commented out code in the OpenSCAD source. Afterwards, I used plastic putty to reduce the seem, and then painted it up.

Maybe I didn't special case 'TIPI' and just allowed any 4 letter names... when Arcadeshopper shares a screenshot with the SNUG voice card, it lists a pile of other stuff... maybe I should just let the future happen when/if it happens and add a known device name list.

ArcadeShopper also noted the SAMS memory conflict with ROS CFG1 and the Force Command LOAD command. I configure SAMS if detected, so that the first 8 pages are mapped into the 32k memory expansion without page number gaps.. This is different from transparent mode. So, I needed to restore transparent mode before loading an EA5 type program that has no expectation of other programs having gone before it... Otherwise when it turns sams mapping on, the loaded program gets swapped out/re-arranged and crashes. so, this is fixed in version 1.3 - as usual, see post #1.

The bank normalization on startup shouldn't impact Force Command, it has starting point replicated in all banks, that does that also. Those ROS names setup in the CFG1 program are in the device names in the Device Service Routine entry list... my DRIVES command only lists things in the DSR lists, not the subroutine/CALLs lists. It also only lists 4 letter things ending in numbers along with special cases for TIPI, and PI - I have a separate LVL2 command that list the BASIC subprogram names, but only the ones with single character names. But I have to admit, maybe CALLs doesn't mean TI BASIC CALL... cause I've never bothered to learn ROS. I assumed they are some sort of shortcut device names like Gazoo had in XB2.7 Suite to trigger different cartridges with DSRLNK names, but that doesn't seem to be the case. - I'll have to go read. ( manual found and read... My assumptions are correct, just didn't realize I have to put stuff on the first ramdisk for them to do anything )

Maybe someone else on here has an HRD4000B, and can confirm the failure?

So, your object file doesn't look like it is a FIAD, not sure if you are using DIS/FIX options for native files. Second, your source should have a DEF and label and that sets up the symbol you can use as an entry point. His tutorial example dump of the object file shows the START near the end in the DEF table. I don't see a hint of that in your dump.

So, I got my MAME (ver 220) working again... ROS842C loaded up... and the latest Force Command seems to work fine with it. `CD DSK5` works, `CD DSK5.` works... I was still able to copy a disk full of junk to a ROS drive. DIR it, and such... Note, you do not have a device name conflict for your ROS drives, so you should not need to use the crubase naming scheme to disambiguate. You do have name conflicts with the TIPI, IDE and Floppy controllers DSK1, DSK2, and DSK3... so those are the only times Force Command might need you to specify the CRUBASE... Force Command's LOAD command doesn't seem to agree with ROS's CFG1 anymore. I think it hangs when detecting SAMS... cause if SAMS is there, I have it all enabled and in use... I need to fix my LOAD command to turn SAMS back off and reset the default bank mapping.

Ok, I must have inadvertently broken something. Hopefully I can get my MAME working again tonight. Supporting things you don't use yourself is always a bad idea. But, that is the road I went down.

Expected hardware compatibility is documented on this page: https://github.com/jedimatt42/fcmd/wiki/Compatibility OS updates or something broke my MAME, so retesting generic HRD compatibility will take me a while. HRD devices have a soft-DSR, so compatibility with Force Command can break with any ROS update also. When I get the HRD emulation running again, I'll document the version of ROS it was tested with.

I tested it months ago with the MAME Horizon Ramdisk emulation using what I think was latest ROS DSR. I will have to try that again, but I haven't changed anything at that level. Try the 'drives' command. What do you see? Some portions may be more strict requiring a '.' at the end of a device name or directory.

No, the old FTP EA5 code would need much more work to do any kind of recursive copy. And it does not copy from TIPI to TI. It copies from an FTP server to the TI. The new versions doesn't move the ball in that direction either.