jedimatt42

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.

Oops, I left the big ROM file out of the zip, cause I had renamed it for experiments with emulators... I've re-uploaded the zip with the rom back in... and an RPK for js99er or MAME use.

More work has been done with the API. allowing for the FTP code to be re-implemented as an external command. Publishing now, so the REDO command recall can be used. FTP can be loaded from the PATH - it is included in the ZIP under FC.BIN. PATH can be set per the examples this post: The FTP command supports a hostname and port argument... like: FTP 192.168.1.105 21 ( I don't remember 21 being a default, but it should be, will be if it isn't... ) A preview of using the API is visible here: https://github.com/jedimatt42/fcmd/tree/master/example/gcc

I don't think you can choose to power part of a chip with SRAM, without powering all of the chip.

Well, 2.12 - 0.7 is 2.5, the latest image that I've produced. So you'll just be back were you started. If people have trouble with updates, try an ethernet cable.

@pcoderdude14 - I hooked my TIPI PI up to a display today, and only see a little trouble, easily fixed in raspi-config The default display mode is 'monitor default' so it detects what the monitor can do, and tries to do that. On my monitor, this partially fails... ( I see this sometimes on my MiSTer as well ) - My symptom is simply the screen image is cut off a bit on 3 of four sides. Going into raspi-config, under the advanced options, and selecting a fixed display mode seems to fix that for me. I've tried 640x480, and 1920x1080 - after that, it doesn't do screen detection, and just uses what it was told, and my issues go away. This isn't exactly your symptom, but it does indicate there can be display specific quirks, that can be cured by using raspi-config -- there is also a screen blanking feature that can be disabled in there. ( I've been exploring this on the PI 3B )

Update 2.12 - 2020-11-08 - FIAD fixer take 2 - (still) happens synchronously during update If you are curious, it logs to the /var/log/daemon.log - it will list each file it is fixing. Most TIers will see nothing fixed cause they have no problems, or were completely fixed yesterday. I do see evidence that bad files have leaked out into community distributions. File copying from TIPI to disks, or DSK images with anything will preserve the error. This is not a problem unless they are intended to be consumed off TIPI by programs that care. File copying back to TIPI also preserves the error. If these leaked malformed files haven't been problematic already, they probably never will be.

1st, do you mean rebooting the PI? Why would you do that? The update process restarts all the services. 2nd, looks like you have an edge case on record size I didn't consider or some foreign or empty files. I will have to update the script, and do more testing I guess. It will have done no harm, but won't have fixed everything. Good find.

Somewhere way back in time, in this thread, Insomnia describes it... basically: * functions are called with BL * they respect R11 as the return address * R10 is the stack pointer, counts down. * parameters are passed in the current workspace as R1 - R8? maybe... I'm sure there is a limit ( it might start using stack after that limit ) * R10 should be the same when the function returns * return value is in R1 * byte type parameters are placed in high byte of register (fact check me) BLWP/RTWP is not used, and R13-R15 are also generally not used. R12 is generally not used, - I've observed the general practice of abusing it in inline assembly, or properly using it for crubase in inline assembly - I don't think I've ever seen it generate code with R0 used. I abuse R0 in my inline assembly. Object files produced are in ELF-32 format (or some elf format), gcc linker also produces an ELF file, gcc objdump tools are used to extract binary images linked to specified addresses ( like program images without the EA5 header ), other tools will convert the ELF to EA5 or ELF to cartridge bin.

Similar to the 4A, the only CPU RAM to execute machine code from is the scratchpad ram built into the TMS9995 CPU.

https://github.com/jedimatt42/TomyTutorKeyboard I don't know words like 'Gateron' but the BOM part of the page says exactly which part I used... which DHE noted above as well. And on my same page you can observe the footprint.

Ok, I lied, it's still morning here... and I've fixed it.. Update 2.11 - 2020-11-07 - Fix TIPCFG to detect major minor version numbers properly. You will need to press FCTN-U in TIPICFG to force the upgrade to this.

Oh yep, I'm just doing a strcmp in TIPICFG... so 2.2 > 2.10

Probably a bug in my version string comparison... I'm used to upgrading from an upgraded state, so I didn't think enough of this. in 'CALL TIPI' / TIPICFG, press FCTN-U to trigger an upgrade even if it isn't detected. This just worked for Arcadeshopper. (I'll take some time off from FTP this afternoon, and fix TIPICFG)