ralphb
-
Content Count
828 -
Joined
-
Last visited
-
Days Won
1
Posts posted by ralphb
-
-
Odd layer is right... Looks like it was called 'hidden' in KiCad
I was able to check another box and plot the gerber silk screen containing the 'U1', 'C4' labels... but not the values like 100nf, or the part names like 8515... Any hints?Yes, I hid the references, since I wanted to plot the values instead. If you edit the values you'll see that they're in "F.Fab" instead of "F.SilkS" ...
I'll push a fix later this weekend that moves them to F.SilkS.
-
2
-
-
Not quite. All emulators need some sort of meta information on what to do with the raw dump data, and they all use their own format. IIRC TI99/Sim has a command line tool to convert dumps to its own cartridge format.
The FlashROM 99 doesn't use meta information, as it only supports one type of dump. If those files are not palatable to the conversion tool you could try the MAME/MESS cartridges, just one folder up.
-
There's WHTech.com, which is a treasure trove of all things TI. It also contains all sort of cartridge dumps.
And there's a new folder of known good, single file, uninverted images that can also be used for the FlashROM 99.
If some image is not working just let me know and I'll add to the compatibility section on the FR99 homepage.
-
7
-
-
OK, I see, thanks! I'm afraid your maxed out system does interfere, or maybe it's just the controller which doesn't play nice. I now properly transferred your CHARA1 to my CF7+, and it's working flawlessly, even through the FlashROM 99 menu.
Having just one image on the SD card will load this image automatically upon startup and then transfer control to the TI 99 forever. In other words, the cart behaves entirely like a plain ROM cart. If this isn't working, then burning the image to an EPROM won't work either. (There's bank switching circuitry on the cart, but the 8K file is mirrored into all banks, so stray MOVs to ROM shouldn't affect execution.)
And I'd like to stress again that images for the FlashROM 99 aren't special in any way. The 4ADOS.BIN above is simply the dump of the original cartridge. If that is not working, then chances are the original cart won't work either on your system. Which dump does your Supercart contain?
Mind you, that's not my final verdict, just my working hypothesis.
Let's see what others report for that program.-
2
-
-
4ADOS also works for me, at least with the CF7+. (Except I didn't quite know what to do with your sort-of-TIFILES file ... what's the native file format? PROGRAM? DIS/VAR? Record length?)
Maybe one of your PEB cards is interfering, but then I would hazard a guess that this is not FlashROM specific, but inherent to the image. Please try the above at some point, I'm curious to know what might cause this.
-
OK, this probably warrants further investigation, and also more user reports. Console Writer is working for me, with both CF7+ and PEB + TI Controller.
But please test again using the FCTN-= method described above, or using only one image per SD card. This ensures maximum compatibility, as the image selection software won't interfere.
-
I couldn't test this program, as I don't have the matching disk image. Could you perhaps post it here?
Also try the following: load 4A/DOS as before, when running hit FCTN-=, then re-select 4A/DOS from the menu. (If FCTN-= is not working, try putting 4A/DOS as the single image on the SD card, and power on.) Does this work now?
-
Great writeup, save2600!
I just would like to take the opportunity to point out again the homepage that contains information about what images can be used, and the repository with build instructions. KiCad placed all values in an odd layer so that they didn't wind up in the silkscreen. Unfortunately I didn't notice until I got the boards.
At least jedimatt42 didn't, either. Second batch is better, I hope.And regarding image types: In the prototype I had the cart recognize and auto-join split images ...C.BIN, ...D.BIN, but when I put more than 50 images on the SD card, startup suddenly took more than a minute! As it turns out, opening a file by name (or checking if a file exists) is not an instantaneous operation (duh!), but requires the linear scanning of the entire directory, which is costly on the 8515. So if I do this for every file in order to check if there's a companion, I spend a lot of time (i.e., n^2) scanning, and the LED remains lit for unacceptable times.
If conventions C, D, G, 3, 8, 9, ... were universally adhered to one could do better, but I thought it will be less confusing to assume a single, linear, non-inverted plain memory dump. Note that split images can be joined by COPY /B on Windows or cat on OSX/Linux (see homepage), and inverted images can be un-inverted by this script (Python) or Rasmus' tool (Java).
-
6
-
-
It did not last long!
Dammit. I'm still waiting to read my 30-year-old disks again ...
-
Ralph,
I have a quick technical inquiry about the cartridge. Besides reading & loading programs, does the cartridge also support writes to the cartridge from the TI? Say instead of "DSK1" or "HDX1", instead have something like "SD1"?
No, that is not possible; at the very least you'd need a DSR somewhere, and there isn't.
What you could do in theory is that you make it RAM instead of ROM (and add a "dump RAM to SD card" button), but this would interfere with the bank switching, and there's absolutely no existing software for such a cart.
-
1
-
-
Most certainly, Matt. I opted not to include the HEX file in the repo in order to not encourage rip-off artists running straight to ebay. It remains to be seen how well that works.
But I'm including the HEX file with every PCB I send out, and if you do the PCB yourself just send me a note and I'll mail you a copy. (Which, in your case, I just did.)-
4
-
-
Thanks for your patience, I think we're ready to release the project.
The FlashROM 99 supports ROM-only images of up to 32K that use the write-to->60xx bank switching scheme. It will not work with programs using GROMs or CRU-based bank switching. The cartridge does not require the PEB and runs on both PAL and NTSC consoles.
For detailed information about the FlashROM 99, please refer to the homepage. This page will tell you how to use the cart, how to handle images, how the cart works on a high level, and potential compatibility issues of individual images.
The GitHub repository contains all files required to build the FlashROM 99 from scratch, and you're encouraged to do so. To simplify things I'm also offering professionally made PCBs, pre-programmed ATmega 8515s, complete kits and fully assembled carts, shipping worldwide. Please send inquiries by PM or by mail to <[email protected]> (preferred).
Note that the FlashROM 99 is a hobby project, and I'm not a Chinese factory. Parts are shipped right away, but assembled carts may take a few weeks before they're ready. If demand is very high, I'll give some preference to active members of the AtariAge TI community.
Finally, many thanks go to the testers Jim, Jon, and Oliver, for assembling their prototypes and throwing all sorts of images at it.
The FlashROM 99 is open source hardware, and everyone is invited to study its design and contribute improvements, be it software or hardware!
-
19
-
-
Thanks for the hint, Rasmus, I had missed that.
-
That ^M window is what I'm actually referring to. And if I may continue to offer feature requests, then adding the VDP registers to that window's drop-down list would be nice as well (if those registers are implemented as memory).
Personally, I don't see the debugger as a means to debug programs, but more as a general tool for observing the state of the emulated machine when running.
-
Oh, I see. Well, if it's technically not feasible (or requires excessive effort) to edit ROM then that's fine. I was just arguing preemptively against writing to ROM not being "accurate".
-
Another suggestion:
It would be really helpful if you could change ROM contents in the debugger as well. Why would the debugger need to adhere to emulated hardware limitations? IMHO the debugger isn't part of the emulation.
-
1
-
-
Can't help you with the nanoPEB, as I have a CF7+, but you could try xvm99 to manage nanoPEB/CF7+ volumes and xdm99 to manage disks (on a Mac, I presume
). -
Back to KSCAN:
I'm still having a hard time to get SCAN run reliably after a soft reset. I would assume that a soft reset would initialize the scratchpad RAM sufficiently so that I could call SCAN with this code:
.
keymode: equ >8374 keycode: equ >8375 gplst: equ >837c c_stackptrs: data >9e7e c_newkey: data >2000 limi 0 lwpi >83e0 ... input: mov @c_stackptrs, @>8372 ; restore stack pointers for SCAN wait_key: clr r0 mov r0, @gplst mov r0, @keymode bl @scan li r0, ' ' movb @gplst, r0 coc @c_newkey, r0 ; new key pressed? jne wait_key.
The problem seems that after a soft reset, SCAN returns that a key has been pressed even though there hasn't, or if it already picks up my "2" from the menu selection then it's returning a different key. I do mess around with the scratchpad up to >8360, but the code is working on hard reset, just not on soft reset.
Before I look somewhere else, is there anything else I need to initialize for KSCAN (that the startup didn't)? -
Why even obsess with the particular IC used for banking? I can force a 377 instead of a 378 into a red board, and it'll work. I can build boards that use two 377s, or a 273 for bank switching ...
If you'd just have "pagedn" and "pagedi" (and optionally another attribute to override the bank count derived from the file size) you could cover any board.
-
Last evening I was chasing a bug in my program that ran fine on MESS, but crashed on real iron. Yes, the issue was uninitialized RAM that happens to be all zero in MESS.
Could we get RAM contents randomization at startup? This would even increase the fidelity of the emulation, no?
(Classic99 has this feature, but in this particular case the likelihood is 65535/65536 that I was too stupid to use it correctly.)
-
1
-
-
Use the source, Luke?
(maybe this can answer your questions)Indeed.
For the 378:.
// Bits: 0110 0000 0bbb bbbx // x = don't care, bbbb = bank if ((offset & 0xff80)==0x6000)
.
Why do you insist on the upper bits being 0? This is what breaks Pac-Man. Personally, I'd make this
.
// Bits: 011x xxxx xbbb bbbx // x = don't care, bbbb = bank if ((offset & 0xe000)==0x6000)
.
Would that break other, modern programs? (I just noticed that's what you do for the 377, so why not for the 378? Is it not true to the original enough? I haven't tried it, but AFAIR the red board also ignores those bits.)
-
Sorry, I meant the emulation. And it's not really crashing either, but Pac-Man is stuck in it's bank-switching loop. For example, it's writing to >646c, but of course the programmers only cared about A1 (modern naming) back then. I don't know how you decode the bank switching, but I duplicating the image should nullify the larger address space when bank switching.
I just thought that previous MESS versions might have a different decoding than you described above.
-
Ah, that's useful, thanks for the update. I guess I can live with padding for now.
(My MESS still crashes on the duplicated Pac-Man w/378, whereas the original one works. I'm a few MESS versions behind, though, I'll check with the latest one again.)
-
Michael, what's the current status with MESS and homebrew cartridges? According to Ninerpedia, there's only 379i, but no 378.
Could we get a generic 378/379 layout where we can specify the number of available banks in the layout.xml? That would make it much simpler to emulate real iron homebrew cartridges, other than the known color boards.
Case in point, as a workaround I'm trying to run Pac-Man in 379i mode, so I took PACMAND and PACMANC and duplicated those 16K up to 128K, but the program still crashes as soon as Pac-Man opens his mouth for the first time. Is 379i bigger than 128K now?
Configurable banks and invertedness would make it much simpler to replicate the cart one actually has.
(Couldn't find the actual MESS thread anymore, but this one seems even better.)
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Flash ROM Cart
in TI-99/4A Development
Posted
No, unfortunately not, it requires re-compilation and re-programming.
The 8515 has lots of I/O pins, but very little storage space, e.g., only 8K for programs. Of those 8K, I only have about 100 Bytes left. Enabling multi-file requires you to disable FAT16, or things won't fit into 8K. (The 1284, by comparison, has 128K of ERPOM for programs.)
There was also no room left for a boot loader that would allow for updates from the SD card.
But note that multi-file wasn't really practical ... startup time for more than two dozen images was outrageous. The reason was again lack of RAM: the 8515 only has 512 Bytes of RAM (twice a TI 99!
), and 256 Bytes of that are needed for data transfer from the SD card. This means I cannot save filenames for sorting or finding matching pairs of files. The code could be improved upon by enforcing the conventions described further above, but I feel this would work only for power users, whereas most people would wonder why THEPOND.BIN isn't found. 