+Ksarul Posted June 6, 2016 Share Posted June 6, 2016 There are often a dew bytes of difference between controllers for the file buffers. You will also run into this issue with the BwG controller, IIRC. I think it reserves an additional six or eight bytes. . . Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 6, 2016 Share Posted June 6, 2016 Oh, I see. I couldn't start the editor, as typing EDIT yields some error, again both in MESS and with the FlashROM, so I thought the load was bad. If this is to be expected, then it seems that the CF7+ is working. ... EDIT requires on the stack a block number to edit: 2 EDIT will start the editor by loading block #2 from the current blocks file. Executing just EDIT will cause a stack underflow and, possibly, an attempt to load a block with whatever 16-bit value is under the stack, which is the first 2 bytes of the TIB (Terminal Input Buffer), which is the ‘ED’ of EDIT , which has a value of 4544h (17732 decimal), which means it will try to load block #17732, which is well past the end of any blocks file and would definitely throw an error. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 6, 2016 Share Posted June 6, 2016 ... I also noticed that the disk activity indicator on the CF7+ lights delayed for later blocks. During loads, each block is interpreted before the next block can be loaded. Some blocks definitely take longer than others to interpret. Each block is loaded into a 1024-byte buffer in low RAM and interpreted. When/if --> is encountered by the interpreter, the next block will be loaded and interpreted. ...lee Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 6, 2016 Author Share Posted June 6, 2016 Thanks, Lee, for the explanations. So it's working fine with FlashROM and CF7+, but erratic with the PEB. Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 6, 2016 Author Share Posted June 6, 2016 That sounds suspiciously like either a timing or a power drain issue. One other thought--it might still be stepping on one of the buffers for the FDC while the software is running. From all these I'd go with timing, although I don't see what a Multicart is doing differently ... Ksarul, could you elaborate on your buffers idea? Are you suggesting that the FlashROM overwrites VDP RAM used by the controller? In single image mode the FlashROM should behave exactly like a 32K-Multicart, so if the original image works with the PEB, the FlashROM should, too. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 6, 2016 Share Posted June 6, 2016 Ksarul, could you elaborate on your buffers idea? Are you suggesting that the FlashROM overwrites VDP RAM used by the controller? In single image mode the FlashROM should behave exactly like a 32K-Multicart, so if the original image works with the PEB, the FlashROM should, too. Are any changes made to >8370 at any time after powerup but before a selected module gets control? Disk DSRs following the TI model set this to the highest available VRAM, which is the highest VRAM byte, which, if changed, will not step on the disk buffer area at the top of VRAM that the DSR reserved at powerup. ...lee Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 7, 2016 Share Posted June 7, 2016 Here is what I've done hardware wise: I've stripped the machine down to: 4A F18A PEB 32K TIFDC +80 track DSK1 - GoTek Hxc2001 firmware DSK2 - 3.5" FbForth is alone on the microSD card. DSK1 /w FBFONT, FBLOCKS, etc.. FBFONT loads corrupted most of the time. FBLOCKS reads corrupt and I rarely get the 'MENU' message. Sometimes I get the menu message, but the MENU command just produces a '?' DSK1 /w empty HFE DSK2 /w FBFONT, FBLOCKS, etc.. restart cart, no DSK1.FBLOCKS found. But forth works well. USEBFL DSK2.FBLOCKS 1 LOAD MENU and I get '?' 2 EDIT shows me a block with garbage binary at the top. Power down... Put TI RS232 w/HDX mod back in the PEB Power up... no DSK1.FBLOCKS found, GOOD! USEBFL HDX1.4TH.FBLOCKS 1 LOAD MENU (success!) 2 EDIT - block looks good, F4 all the way through, everything looks good. ( I also compiled DARKSTAR off of my HDX, and it compiled with only warnings about things that have now become resident in the cartridge. The game didn't actually run however... --- Is it possible the cart is responding on the data bus when the floppy controller is being addressed? Or the address bus? Lee - the assembly code for the menu is here: https://github.com/endlos99/flashrom99/tree/master/ti Maybe you can spot something. I'll pull the HDX back out for baseline, and try console writer now. -M@ 3 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 7, 2016 Share Posted June 7, 2016 The console writer test fails... writing to a disk, corrupts the disk, gloriously. I tried the floppy and the gotek. What a weird little program... click click click click... (oh, and I didn't specify earlier, but my 4A is an NTSC model.) -M@ Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 7, 2016 Author Share Posted June 7, 2016 Thanks for the diagnostics, Matt! So we have now: TI controller: broken CF7+: works HDX: works Would be interesting to see if other controllers and the NanoPEB work or not. I'll write a program to do some systematic testing. Console Writer is easily dismissed, but I certainly would like fbForth to be working. The FlashROM is in tri-state mode unless ROMS* is low, similarly the bank switch is only enabled when ROMS* is low. So unless the TI controller is poking around in cart space I don't see yet how this could affect execution. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 7, 2016 Share Posted June 7, 2016 Anyone have the FlashRom 99 and one of the other floppy controllers? To make life easier on myself, I hex edited the fbForth 2.0:8 rom, so it would look on HDX1 for FBFONT and FBLOCKS. I only use my floppies/gotek when I really have to anyway So, I'm still very happy with my FlashRom 99 carts. So, a couple non-TI DSRs work. I wonder if Lee was on to something with the state of VDP/disk buffers? -M@ Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 7, 2016 Share Posted June 7, 2016 Here is what I've done hardware wise: ... For the TI controller, what do you see in >8370? It should be >37D7. Add 1 to whatever you get and check the first 6 bytes at that VRAM address. In hex, they should be AA3F FF11 0300 If the value in >8370 is not >37D7, check the first 6 bytes at VRAM >37D8, anyway. What are they? Lee - the assembly code for the menu is here: https://github.com/endlos99/flashrom99/tree/master/ti Maybe you can spot something. I'm looking but don't see anything, yet. ...lee Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 7, 2016 Share Posted June 7, 2016 Anyone have the FlashRom 99 and one of the other floppy controllers? To make life easier on myself, I hex edited the fbForth 2.0:8 rom, so it would look on HDX1 for FBFONT and FBLOCKS. I only use my floppies/gotek when I really have to anyway So, I'm still very happy with my FlashRom 99 carts. So, a couple non-TI DSRs work. I wonder if Lee was on to something with the state of VDP/disk buffers? -M@ I should have mine today hopefully it's been camped out at the post office for 24 hours.. I have a corcomp controller in my 4/a Greg Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 7, 2016 Share Posted June 7, 2016 What are the chances that the disk I/O issue might be solved with a firmware update of the Atmega? The chip is in a socket, so theoretically it could be pulled and re-programmed. Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 7, 2016 Author Share Posted June 7, 2016 (edited) To examine the erratic behavior I wrote a little test program that reads disk sectors and dumps them on the screen. There's a special disk image that contains well-defined sectors so that errors are easily spotted. The first image shows my main TI system with PEB that contains a stock TI disk controller, 32K, and RS232. The second image shows another system with a similarly configured PEB. In the first system, the FlashROM works, in the second system, sector reads fail. In fact, my main system passes the fbForth test. I see no difference in both systems whatsoever. But looking at the bad system we can see that only 16 bytes of sectors are read correctly, and the status code returned by DSRLNK >0A is either >22 or >23 (top right). There's also a second image that works just like the first one but moves the entire code to RAM first, so that it's running from RAM instead of cart ROM. That yields the same result, though. So whatever it is, the mere presence of the FlashROM seems to mess with disk I/O, at least with the TI controller. Right now I don't know how to interpret this, but it would be interesting to see if Matt or Omega get more or less than those 16 bytes. diag.zip EDIT: Just had an idea -- I ran the sector test from RAM, got errors, physically ripped out the FlashROM, program kept running from RAM, error gone! So the cart does influence data transfer on the bus ... I'll have to meditate on the schematics for a while. Edited June 7, 2016 by ralphb 2 Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 7, 2016 Share Posted June 7, 2016 What are the chances that the disk I/O issue might be solved with a firmware update of the Atmega? The chip is in a socket, so theoretically it could be pulled and re-programmed. We can hope to dream I was just thinking, I'm glad I waited for my sockets and didn't just solder the 8515 into the board. I had to argue with myself Saturday while waiting for the sockets to arrive. Luckily, I won. Oh, I suppose if I was smart, I could compare some memory state when loading fbForth off of the Flashrom vs. the black-board-eprom... I should have time for that sort of thing on Friday. -M@ 1 Quote Link to comment Share on other sites More sharing options...
sparkdrummer Posted June 7, 2016 Share Posted June 7, 2016 How much does one of these cost? I have a myarc hfdc and corcomp in one peb and a myarc dsqd and wht scsi in the other. Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 7, 2016 Author Share Posted June 7, 2016 What are the chances that the disk I/O issue might be solved with a firmware update of the Atmega? The chip is in a socket, so theoretically it could be pulled and re-programmed. That really depends on what is causing this, but ... it's not looking good. Oh, I suppose if I was smart, I could compare some memory state when loading fbForth off of the Flashrom vs. the black-board-eprom... I should have time for that sort of thing on Friday. The diag program above will probably suffice. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted June 7, 2016 Share Posted June 7, 2016 ... Right now I don't know how to interpret this, but it would be interesting to see if Matt or Omega get more or less than those 16 bytes. ... EDIT: Just had an idea -- I ran the sector test from RAM, got errors, physically ripped out the FlashROM, program kept running from RAM, error gone! So the cart does influence data transfer on the bus ... I'll have to meditate on the schematics for a while. That's great progress I'll steal a chance to confirm these results before bedtime... -M@ 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 7, 2016 Share Posted June 7, 2016 Right now I don't know how to interpret this, but it would be interesting to see if Matt or Omega get more or less than those 16 bytes. Quote Link to comment Share on other sites More sharing options...
ralphb Posted June 7, 2016 Author Share Posted June 7, 2016 Thanks, Omega ... same thing! (Sectors 1-360 contain consecutive byte values that are easy to assess, but I think it's safe to assume that Omega's system also reads exactly 16 bytes.) 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted June 7, 2016 Share Posted June 7, 2016 (edited) Hi Ho Ralph, I´ve also done this 2 tests, here is my result. (Pls don´t ask me what this all means ) Games a.s.o. are running fine EDIT: This test was done with a BwC-Controller and 32KB Edited June 7, 2016 by schmitzi 2 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted June 7, 2016 Share Posted June 7, 2016 Hi Ho Ralph, I´ve also done this test, here is my result. (Pls don´t ask me what this all means ) Games a.s.o. are running fine EDIT: This test was done with a BwC-Controller and 32KB Hah! @Schmitzi, you're too much! Looks like everything is as it should be—your learning curve included! ...lee 2 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted June 7, 2016 Share Posted June 7, 2016 haha yes, was a short fiddle-riddle, my luck :) thanks Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 7, 2016 Share Posted June 7, 2016 (edited) Thanks, Omega ... same thing! (Sectors 1-360 contain consecutive byte values that are easy to assess, but I think it's safe to assume that Omega's system also reads exactly 16 bytes.) Yeah, bummer huh? It'll all work out eventually, in the mean time... ...it sure makes for an awesome "UMGC" (Ultra-Mega Game Cartridge). It also paid for itself today! I was able to re-task a few of my UberCart boards. Edited June 8, 2016 by --- Ω --- 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted June 8, 2016 Share Posted June 8, 2016 mine arrived today!!! 3 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.