This is because the sdcard browser makes assumptions about the implementation of the Loader in various ROMs. See https://github.com/kervinck/gigatron-rom/pull/216 for the explanation and for a fix. The updated sdcard browser is both in https://github.com/kervinck/gigatron-ro ... ser_SDCard and https://github.com/kervinck/gigatron-ro ... /BabelFish .
Update: I realized that the revised Browser does not fit in the Pro Micro Flash. Try the attached one instead using the sketch https://github.com/kervinck/gigatron-ro ... /BabelFish. The diff is visible at https://github.com/lb3361/gigatron-rom/ ... 93fea4331a ...
SDCard browser for Pluggy Reloaded:
Forum rules
Be nice. No drama.
Be nice. No drama.
Re: SDCard browser for Pluggy Reloaded:
- Attachments
-
- Browser_SDCard_ROMv2_v1.h
- (18.63 KiB) Downloaded 120 times
-
- Browser_SDCard_ROMv2_v1.gt1
- (3.1 KiB) Downloaded 104 times
Re: SDCard browser for Pluggy Reloaded:
So I can use DEVROM as it is and only update Pluggy Reloaded?
Edit: Updated Pluggy Reloaded software and using ROMv5a and DEVROM now it works. Thanx.
Edit: Updated Pluggy Reloaded software and using ROMv5a and DEVROM now it works. Thanx.
Re: SDCard browser for Pluggy Reloaded:
Hello:
In Pluggy reloadaded (no ROM version), after programming the arduino with BabelFish.ino (located in dropbox no-ROM repository at the beginning of this thread), what have to to with the above file, Browser_SDCard_ROMv2_v1.gt1? Where to put such .gt1 file?
thanks
In Pluggy reloadaded (no ROM version), after programming the arduino with BabelFish.ino (located in dropbox no-ROM repository at the beginning of this thread), what have to to with the above file, Browser_SDCard_ROMv2_v1.gt1? Where to put such .gt1 file?
thanks
Re: SDCard browser for Pluggy Reloaded:
Make a Babelfish -folder and put these files from the github links and above there. The IDE will find them when click open BabelFish.ino. Then use verify/compile to make sure. Programmer will send it to "arduino".
Re: SDCard browser for Pluggy Reloaded:
The file Browser_SDCard_ROMv2_v1.gt1 must not be copied in the root directory of the SD card with a special name?
Re: SDCard browser for Pluggy Reloaded:
The NOROM version of SDCard Babelfish loads the SDCard Browser from the Pluggy Reloaded into the Gigatron since the browser is not built into other ROMs outside of the SDROM. You need to put both files into the same directory as the .ino file so that it is compiled into the Babelfish image. You don't have to load either of these files into your SD card
Re: SDCard browser for Pluggy Reloaded:
The gt1 file is the source of the h file which is included by the Arduino sketch. When you press CTRL+F2, the Arduino sketch sends this GT1 file using the Loader protocol. When executed, this GT1 file runs the browser. The browser talks with the Arduino using a protocol that lets it request the contents of a directory or request a particular file. After requesting a file, the browser starts the Loader program, and the Arduino sends the requested file using the Loader protocol again.
This is in contrast with the case of a SD card attached to a SPI port on a RAM expansion board. When the Gigatron boots and senses the presence of such a SD card, it runs the CardBoot program instead of the Main menu. Cardboot locates a file named system.gt1 on the SD card, loads it, and executes it. This file contains a minimal OS able to read FAT-formatted SD cards and a browser. No external microprocessor is needed.
This is in contrast with the case of a SD card attached to a SPI port on a RAM expansion board. When the Gigatron boots and senses the presence of such a SD card, it runs the CardBoot program instead of the Main menu. Cardboot locates a file named system.gt1 on the SD card, loads it, and executes it. This file contains a minimal OS able to read FAT-formatted SD cards and a browser. No external microprocessor is needed.
Re: SDCard browser for Pluggy Reloaded:
where is the file sdcard.asm.py needed to build sdcard.rom from source code? It is not in dropbox repository in the first page of this thread (https://www.dropbox.com/sh/sw0etxvv6z54 ... 1NEsa?dl=0)
Re: SDCard browser for Pluggy Reloaded:
I'm adding some optimisations to the Browser this weekend, so the ROM and NO_ROM versions will be getting another update.
I'll update this thread, the DropBox links and the main repo when it's done.
These new links will supersede all other/old links.
The browser did assume that NextByteIn_32 would remain fixed at a static address within the same versions of ROM's and I take blame for not making this a formal documented definition before merging pull requests for changes to DEVROM. Now we have a couple of versions of DEVROM with differing addresses for NextByteIn_32. In a perfect world all of the ROM functionality would be relocatable and accessible from ROM_interface.json, but that's not possible for a variety of reasons, (including not being able to predict what internal native routines will need external access, like NextByteIn_32).
So from now on, native system routines such as NextByteIn_32 and friends, must not move from their known addresses within a ROM version, this will allow programmers to rely on the addresses of internal routines based on the initial ROM in a new family. (I will document this formally in the repo Doc folder).
I'll update this thread, the DropBox links and the main repo when it's done.
These new links will supersede all other/old links.
The browser did assume that NextByteIn_32 would remain fixed at a static address within the same versions of ROM's and I take blame for not making this a formal documented definition before merging pull requests for changes to DEVROM. Now we have a couple of versions of DEVROM with differing addresses for NextByteIn_32. In a perfect world all of the ROM functionality would be relocatable and accessible from ROM_interface.json, but that's not possible for a variety of reasons, (including not being able to predict what internal native routines will need external access, like NextByteIn_32).
So from now on, native system routines such as NextByteIn_32 and friends, must not move from their known addresses within a ROM version, this will allow programmers to rely on the addresses of internal routines based on the initial ROM in a new family. (I will document this formally in the repo Doc folder).