Jump to content

speccery

Members
  • Posts

    920
  • Joined

  • Last visited

Recent Profile Visitors

5,567 profile views

speccery's Achievements

Dragonstomper

Dragonstomper (6/9)

2.2k

Reputation

  1. It never ceases to surprise me how fast time goes... Already half a year no update in this thread. And this update is off-topic, but an update of my recent activities. As background, I've been very busy with work and I guess somewhat tired due to the dark season we're going through in my neck of the woods. Not much energy to work on retrocomputing. Also the hobby seems to go in cycles for me, I've playing with my synthesizers and trying to make progress with my piano playing in the meantime. With that, this update is going to be somewhat off-topic but related to the pico cart one way or the other. Firstly, I've been curious to know if I can manually assemble boards with QFN packaged chips. Two chips interest me in particular: the RP2040 (powers the rasberry pi pico) and ICE40UP5K (small FPGA). In order to test this, I ordered already ages ago (I think maybe already in 2022) boards from PCBWAY with Minimal Design Example by the Raspberry Pi people. No changes on my side at all, a simple two layer board, minimal design for the RP2040. I finally today got around seeing if I can build these by hand. I assembled two boards, and got both working. The first prototype build took something like four hours... A big chunk of that time went into finding the PCBs, components, going through the schematics etc. I don't even want to mention all the mistakes I made - but let me say that I did the big one and despite double checking managed to install the RP2040 chip 180 degrees off first...The other problem I had was that I my micro USB connectors were not the same as in the design originally and it shorted VBUS (the 5V power input) to ground. Once I figured out this was the problem, I was able to fix this easily by just moving the connector a bit. Easy with the hot plate, which I used my hot plate to bake the boards, and that greatly speeded up both the assembly and the numerous iterations of assembly bug fixes. The second board assembly only took about 35 minutes, starting from having the components and the bare PCB, to the board passing a simple test program - the LED blink, although there is no LED on the board so I observed the blinking with an oscilloscope. Here are the finished boards: Here are some pictures of the build process. First after applying paste (in a bad way - too much paste mostly, and not enough in some spots): Then most components placed on top of the paste - including the RP2040 misoriented by 180 degrees... And finally the board after first bake - the RP2040 still in the wrong orientation. I did not realise the chip was mis oriented before applying power... That meant the first chip became toast, but I replaced the chip and put another in place and the board worked If you open the picture and look closely, you can see many solder balls next the QFN chip "pins", there was too much solder paste. Removing the balls turned out to be very easy, just apply flux and give it a touch of the soldering iron, with a pretty sharp tip. The QFN packaged chips don't have any real pins, they just have the contacts exposed at the very edge of the plastic. Despite the numerous problems with the first board I was surprised how easy the QFN packaged chips were to work with. The key is to order a stencil when ordering PCBs, and let solder paste, flux and surface tension do the job. This board also uses 0204 sized capacitors and resistors. I have never so far dared to use these in my own designs. They are very small, virtually inseparable from pecks of dust... But using the stencil and solder paste they were surprisingly easy to work with, you basically just drop them where they need to go and baking takes care of the rest. Except when there is too much solder paste, and they float a bit... Anyway with this experience I'm probably going to design my first FPGA board using the ICE40UP5K. Perhaps I will do a revision of the picocart which would include both the FPGA and RP2040. I think the original picocart design is still the way to go for most DIY people (when I have time and inspiration to finish the firmware) as it is a much simpler build that using the plain RP2040 chip. Then a completely off-topic thing, before the holiday season I completed one of my simple dream electronics projects and built a small mechanical keyboard, pictured below. It is my own design, the Raspberry Pi Pico board to powers it. The board has two quadrature encoders (with push button functionality), 15 Kaihl low profile hot-swappable mechanical switches, and 15 neopixel RGB LEDs, one for each key switch. After building the board and developing some software, I realised that I can run the QMK firmware on it. I also added a screen as an afterthought. The current QMK based firmware supports 4 key layers, one of which is a MIDI layer enabling notes to be played with the keys. Depending on the layer the encoders can be used to control multimedia features such as volume or adjust RGB backlighting effects. I still need to do more work with the firmware, very many ideas where to go from here. Also this design would benefit from not using the Pico board but rather the RP2040 chip directly on the board. I built four of these so far, gave two to my brothers as xmas presents and one to my son Not sure if they appreciate the effort though but fun project - and very tactile
  2. Yes, sure. This was my original thought, before I started to think that loading from disk could be easier for some. I will make an example cartridge image in the coming days.
  3. Thanks, I took a look at the files. There is no documentation how to use GPL@LOADER here, it seems to be an executable program. I assume it is part of the GRAM Kracker software. It does not appear there is source code, that's really what I was looking for. How is GPL@LOADER used? Do you load it with E/A or how does one launch it?
  4. Thanks Fred, this is the information I was looking for! The INT/FIX 128 format is probably the best for me.
  5. I don't think this is what you're looking for, but anyway, for what it's worth: I've been contemplating with the idea of making a simple FlashGROM type cartridge, with only a microcontroller implementing GROM capability and a separate regular SRAM chip connected to the cartridge port (probably also with latch to support paging of SRAM if larger than 8K, and a little glue logic to choose whether writes from TMS9900 go to SRAM or the address latch). I've advanced my grommy2 project lately, and this idea of MCU+SRAM came to mind. Looking at documentation on TI Tech Pages, it appears that GROMs can contain power up routines. Such a routine could copy initialisation data from GROM space to SRAM, making the SRAM work like ROM. Although I've been thinking about this idea in the context of a very simple cartridge, there's nothings stopping using the same idea to init a DSR RAM from GROM. A single GPL instruction MOVE >1000,G@>8000,@>4000 would copy 4K of code from GROM address >8000 to the DSR RAM (provided the DSR memory was enabled with the right CRU settings).
  6. I created the first version of the config tool for grommy2. I continued to write this on GPL. There are two screens, and single keystroke commands (in the time honored way commands are issued on the TI) are used to perform actions. Here is the main screen, under js99er.net. I have also run this on the real hardware. The version number is 0.0.99 when grommy2 is not detected. The second screen, accessed with command 9, has a GROM dump tool. It also will have the ability to flash a new firmware, provided it has somehow been loaded to the 24K GRAM. Here is a screenshot: I attach the new config.bin, a GROM cartridge image which can directly be loaded with js99er or presumably any other emulator. It can be tested (the GROM dumping thing) without a grommy2, it will just show contents of GROM. But this is shockingly slow! Probably the GPL code could be optimised further. The source code config.gpl can be found here. This second screen is a bit cryptic, but there are 4 commands: 1 : Decrement GROM address by 64 (hex 40) and dump 64 bytes 2 : Increment GROM address by 64 and dump 64 bytes 3 : return to previous screen. 0 : flash firmware (not implemented yet but trivial) So here pushing 1 or 2 will show the next crop of 64 bytes of GROM contents. But it is dead slow, you can see as the progress as the code updates the next page. I did not have high expectations for GPL execution speed, but this still is slower than I expected (haven't tried this screen on the real iron yet). Given that for me it is much harder and slower to write GPL than assembler code, I really was hoping this would go faster. Well, a piece of GPL code can always copy machine code snippets from GROM to the scratchpad memory and use the GPL instruction XML to run it, perhaps that's the way to go. I went with GPL since I want this config tool to run from the grommy2 without additional hardware (the code is currently less than 2K and will fit into the unused areas of GROM space). Then a question: to update the firmware, the new firmware needs come from somewhere. Perhaps it should be in a disk file. Does anyone have a piece of GPL code which would load binary data from disk? I also wonder what would the right format for a disk file, probably a 80 byte fixed record file as there are no pure binary streams to my understanding available. What I need is a way to load 24K of payload from a file to GRAM. A simple way would be use the LOAD PAB opcode, but that is limited to what can fit in the VDP RAM given the way the TI works. I could break the 24K firmware to three 8K files, which would then be loaded with the LOAD command to VDP RAM and copied from there to GRAM 8K at a time. But it would be better if the firmware was stored in a single file. config.bin
  7. Hi Arto, my source of information and inspiration with GPL have been the TI intern book (available in PDF format, contains disassembly of ROM TMS9900 code and system GROM disassembly in GPL). However, like I mentioned, the TI Mini Memory module's GPL disassembly files and explanation here are easier to approach and play with. I have said it before, and I will probably say it again in the future, but as a kid I really should have bought the Mini Memory Cartridge instead of extended Basic. They were both bloody expensive at that time and had the same price.
  8. Wow it's been almost 3 years since the last update... I had received reports that the code no longer works with new versions of the oss-cad-suite toolchain. No wonder, as I haven't worked on the project for way too long. The project now works with the 2023-11-18 release which I used during debugging, although I had to disable SDRAM support for now as this is not working anymore. I was using code from @pnr but it instanciates a component which is no longer there. The project is still here at GitHub :) I will try to find a bit more time to work on this thing, I didn't quite remember how cool this one was even if I made it... I have been working on so many other projects in the meantime - and I had a bit of a pause with TI stuff during summer. Perhaps it's time to enjoy some more FPGA goodness. Maybe I will combine a couple of projects - I could expose a GROM port on the GPIO pins of the ULX3S and connect that to the Grommy2 board for example. The nice thing is that with the ULX3S I get HDMI output. Although at the moment the video mode I use does not work with my capture device, need to see if I can increase the resolution.
  9. I updated the '1bpp2basic.py' python script so that it now also creates a GPL version of the screen definition The new version is on my Github repository. I also created a module header & setup program called config.gpl (inspired by the setup code from Mini Memory) which includes the generated screen.gpl code and draws the screen. The code is compiled with python3 1bpp2basic.py xga99.py --aorg 0x6000 config.gpl -L config.lst -o config.bin and the generated config.bin file is a small GROM image which can be loaded with js99er.net. Since the name ends with a 'g' the emulator detects its a GROM. The BASIC program SCREEN.BAS is still generated as well. Compared to the BASIC program, the GPL code is more compact (if you only consider the screen definition) and very fast. Below is the output rendered by the example GPL, I also attach the GROM image 'config.bin' which can be loaded to an emulator. It is not very interesting, as there is no interaction. But anyway this completes the workflow from a 1bit per pixel BMP image to a GROM image. Also, the source code config.gpl might be interesting to someone willing to learn GPL (I still learning myself). config.bin
  10. My next step in this project is a program, running on the TI and probably written in GPL, which will create a simple user interface to display the status of the grommy2 and to perform the typical tasks such as enabling GRAM and copying stuff to it from one of the user GROM banks. I wanted to have some graphics in that as well, and I ended up creating a simple python3 program which converts a 1bpp BMP format picture into a TI Basic program drawing the picture - as long as there are enough user characters available. I'm not going to implement the final program in Basic, but this was a quick way to test that the conversion works and a fun exercise. The code of the python program 1bpp2basic.py is available and "documented" at GitHub: the tool in GitHub Here is the generated BASIC program for the test program. Thus the input is a picture and output SCREEN.BAS listed below. Here is the output captured from js99er.net after running the program:
  11. I don't know where you get this idea of 3*6k capacity with the grommy2. I have all the time communicated that the grommy2 does 3*8k in the system GROM area (meaning the bottom 3 GROMs, total 24k). When loaded with original TI system GROM contents, then only 6k of each of the 3 GROMs contains useful data, and the top 2K of each 3 GROM areas (1800..1FFF, 3800..3FFF, 5800..5FFF) is unused - or available for extensions. The grommy2 has enough flash memory space to provide another 40k on top of the bottom 24K, making a total of 64k. That is not implemented in the current firmware, but would be easy to do - if it makes sense.
  12. Thanks @RXB for the feedback. I was looking for this. Before I respond to your comments, a couple of pieces of background information: the grommy2 is a system GROM replacement device. Due to this, it only has access to GROM signals. It is not connected to CRU signals nor can it act as a normal RAM or ROM. It can only do its thing in the GROM space. It cannot support multiple GROM bases, since being compatible with the GROM chip pinout it is not connected to extra address lines. I on purpose limited the address range it covers to the system GROM area. Remember that this thing plugs inside the console in the place of the GROM chips. If the grommy2 was to serve GROM addresses beyond 24K, it would conflict with GROMs connected to the cartridge port. Unlike the normal system GROM chips with weak data bus drivers, the grommy2 has strong drivers and would overpower GROMs connected to the cartridge port. As the documentation says, it operates always in 8K GROM mode. So not 6K but 8K per GROM for a total of 24K with 3 GROMs. The exception is that the command interface is at address 5FF0, masking the top 16 bytes of the 3rd 8K GROM. Indeed the command interface, being at the top of 8K GROM slot #3 does not interfere with any 6K GROMs. I can make the command interface more sneaky to enable access to those 16 last bytes in the system area if needed. I can place it anywhere in the GROM space, for example to FFF0..FFFF. The grommy2 could easily serve the entire 64K GROM space, but the problem is, what happens if you plug in a cartridge? I suppose I could add some sensing code to only serve the area from >6000 onwards if nobody else is driving the bus then, but that functionality would need to rely on heuristics. Please enlighten me, I posted the spec to collect feedback. Please also note that there are other devices, like my StrangeCart cartridge, which can act as a large GRAM and large RAM/ROM simultaneously. With regards to hardware vs software know-how, I do much more software than hardware, also professionally I've done much more software than hardware design. I enjoy both
  13. I spent this weekend a couple of solid sessions on improving the grommy2 firmware and testing it. It now has a pretty solid level of functionality, I still need to test the firmware upgrade capability though. I also took some time to write a document about the grommy2 software interface, it's available here in the StrangeCart-Doc documentation tree. It's not the right place for the document, but I wanted to make it available for review immediately. As the document explains, I used some GPL code on a modified version of the Mini Memory cartridge to test the grommy2. Out of the eight commands I outlined in the previous message I have tested five - including flashing of the MCU inside of the TI under the control of TMS9900! In other words, I was able to use GPL code to first copy default GROM to GRAM, enable shadow RAM (i.e. writes) and select the GRAM bank, edit the contents of system GROM/GRAM with a modified version of Easybug, and finally write the modified version to the Flash memory of the grommy2. I tested this with both user banks, programmed them back to the grommy2 and powered off the computer. After powering on again I re-entered Easybug and switched back to user GROM area - and the changes remained! I also realised that the GRAM area can be used as a 24k memory expansion of sorts, and started to think of adding a couple of calls to normal TI BASIC for example to move strings back and forth the GRAM area... I am happy I took the time a week ago to think about the specs as above and got some structure into this project.
  14. The microcontroller I am using in the grommy2 project could easily do this (128k of Flash and plenty of horsepower for something like this). I took a very quick look at the TMS6100 pinout and I think it probably be a simple matter of just wiring the grommy2 board to replace the TMS6100 chips. I can try it out when I have time. I am currently working on the Grommy2 firmware already, although haven't had time to advance it this week.
  15. I've been a little under the weather and watched some retrocomputer related videos. I discovered a ZX Spectrum project from Spain, the Dandanator and its extensions. I studied this project and the code in Github briefly. This somehow motivated me to continue with the grommy2 firmware development, and I was able to spare a few hours during the weekend to work on it. The basic realisation for me was just that I need to limit the feature set to something useful to be able to get a better full-fledged firmware out. A device like the grommy2 can do so many things, that it's easy enter the idea land which leads to feature creep... So I decided to put in some constraints, and I would be interested in feedback from the community. What follows is what I decided to do, and I have already written in the firmware. I have tested most of these features already in isolation on dev board, but I haven't yet tested any of this running when the board connected to the TI. Since the previous firmware version was already working well, I have no reason to think this would be hard to get running. This is the feature set: Four 24K memory banks covering the system GROM area. One of these is active for reads at a time. #0 normal TI-99/4A system GROMs, stored in Flash. This is the default. Read only. #1 user system GROM bank 1, stored in flash. Read only. #2 user system GROM bank 2, stored in flash. Read only. #3..#7 reserved #8 24K GRAM area stored in RAM. By default read only, but writes can be enabled. The RAM area works as a shadow area: when writes are enabled, the written data goes to this RAM, regardless what GROM bank is chosen for reads. Command interface at GROM address 0x5FF0 (last 16 bytes of the system GROM area) By writing 16-byte commands to this memory area, the grommy2 will perform certain tasks The simple command interface implementation means that the system GROM code cannot use the last 16 bytes of GROM. Since normal TI GROM chips are 6k each, occupying a 8k memory slot in the GROM address space - with 2k dummy data at the end - the command interface does not interfere with standard system GROMs. I know there are some extensions of the system GROMs, and if they use these very last 16 bytes there might be a problem. I hope in practice not, and if that happens, the interface can be modified. Commands. At this point there are a 8 commands, invoked by writing a 16 byte command to 0x5FF0 continuously. The commands are: 0: Read version. Makes the grommy2 firmware version information available for reads at address 0x5FF0..0x5FF7. 1: Select GROM bank to be used for system GROM reads. Valid banks are 0..2 for Flash and 8 for GRAM. 2: Copy a Flash bank to GRAM, valid banks are 0,1 and 2. 3: Enable/disable RAM shadow mode. When enabled, writes to system GROM area go to GRAM (bank 8). 4: Write contents of GRAM to Flash bank 1 or 2. One parameter of the write command is a bit mask, choosing in 4k chunks what parts of the GRAM to write to Flash. This can be the entire 24K, or any combination of 4k areas in the 24k system GROM range. 5: Compare contents of GRAM to flash bank 0,1 or 2. 6: Write the contents of GRAM as new firmware for the grommy2. Needless to say this command is dangerous, but allows updating the firmware while the grommy2 is inside the TI without any debugging cables etc. 7: Execute code in the GRAM region by the ARM processor of the grommy2. In addition to the above, I will modify the firmware so that it monitors one of the spare I/O pins of the grommy2 when it boots. Depending on the level of the I/O pin, the grommy2 will boot with Flash bank 0 or 1. This makes it possible to run custom GROM code from the boot. The command set above I think is enough to enable all kinds of use cases: GRAM mode: Copy one of the flash banks 0,1 or 2 to RAM. Switch to RAM bank. Enable shadow ram writes. Run custom system GROM: Select user bank 1 or 2. Write custom GROM contents: enable shadow RAM mode, write new GROM contents by just writing to the system GROM area, and finally issue the command to write the contents of GRAM to flash user bank 1 or 2. After this the contents are non volatile and can be entered by just selecting that bank for reads. Note that the normal system GROM bank can be active for reads throughout this process. Update firmware: enable shadow RAM mode, write new firmware contents by just writing to the system GROM area, and finally issue the command to write the contents of GRAM as new firmware. Note that the normal system GROM bank can be active for reads throughout this process. The system probably needs to be reset after this... I haven't tested this functionality yet. Feedback is welcome.
×
×
  • Create New...