Jump to content

FarmerPotato

+AtariAge Subscriber
  • Content Count

    1,422
  • Joined

  • Last visited

Community Reputation

1,864 Excellent

1 Follower

About FarmerPotato

  • Rank
    Stargunner
  • Birthday 01/01/1971

Profile Information

  • Gender
    Male
  • Location
    Austin, TX
  • Interests
    TI-99/4A. FORTH. Verilog.
  • Currently Playing
    Last year: Port Royale 3, Pocket Trains, Minecraft, Master of Orion II, PacMan 256, Katamari Damacy, We Love Katamari, NY Times Crossword
    This year: Katamari Damacy Reroll, Settlers of Catan Universe, Chisholm Trail, NY Times Crossword

Recent Profile Visitors

5,119 profile views
  1. That is awesome. I only imagined having a demo program or two inside. I had no idea there were so many cool things using built-in file systems! I really like the idea of E/A Complete, or an Adventure cartridge with games inside! And ROMDSK just seems to do everything imaginable...
  2. That's already a neat VDP layout. The sum of the holes would be enough to hold 64 more sprite patterns... But I don't see a way to rearrange it. The stumbling block is that Name Table 2 must have a contiguous 1K block. To get more sprite patterns, you need 2K boundaries. When using just 192 of the patterns, there are two 512 byte holes. No contiguous 1K for the Name Table 2. So you'd have to give up having Name Table pages 0-3. Could your scrolling be adapted to use just two pages? I would mask off the top row, and refill it after 8 pixels scrolled.
  3. I am averse to doing mods on my Geneve (either one.. one has the Cecure +32K mod, the other is factory original with a lot of miles). I'm not sure the benefits outweigh the risk of breaking it. Just having the thing working all the time now is great! I can't imagine having to troubleshoot a non-booting card because a wire fell off. That said, I could be convinced otherwise.
  4. Imagine a card that has a lot of complicated CALL subprograms in DSR ROM. Let's call it a WIDGET. You want a quick way to get some useful parameters set, in order to verify the device works. The obvious way is a short BASIC program. My idea is to embed a few loadable TI BASIC programs in a DSR ROM. The minimal DSR would have a device name WIDGET and support opcode LOAD only. Is there a technical reason why this could not be done? For example: Imagine a config-type program that will offer a short menu: OLD WIDGET.CONFIG LIST 10 PRINT "WIDGET OPERATING MODE? (1-2)" 20 PRINT "1. LOCAL" 30 PRINT "2. REMOTE" 40 INPUT A 50 IF (A<1)+(A>2) THEN 10 60 IF A=2 THEN 200 100 CALL WIDSET(0, 1) 110 CALL WIDSET(4, 5, 5, 128, 6, 47, 7, 129) 120 CALL WIDSET(8, 5, 9, 128, 10, 47, 11, 129) 130 CALL WIDRUN(2) 140 STOP 200 CALL WIDSET(0, 2) 210 CALL WIDSET(4, 11, 5, 0, 6, 49, 7, 129) 220 CALL WIDSET(8, 5, 9, 128, 10, 47, 11, 129) 230 CALL WIDRUN(3) 240 END Then OLD WIDGET.DEMO RUN -- suitable short demo program -- Q. Why not just provide these on disk? A. Because the WIDGET operates nicely on a standalone console Q. Why not just provide these on a cartridge? A. Because I told you the WIDGET operates nicely on a standalone console. Maybe it's a screen dumper and CONFIG chooses your printer mode! Q. Why not just provide one CALL to do the config or demo? A. Besides TI BASIC code provides the right capability and is more instructive. The user may want to make a quick edit to CONFIG. Imagine if the disk controller had come with the CATALOG program built-in. TI BASIC users might have said: OLD DSK.CATALOG RUN and got the usual program into memory immediately.
  5. I thought SID Master 99 was the software, while the card was originally labeled SID Blaster. It's been a while since I looked at @Opry99er's card, so I might be wrong. The other software was MIDI Master. Also, in the 90s, Creative Labs was ready to sue anybody who made a '*Blaster' and I think they registered 37 variations as trademarks.
  6. How can TIPI PEB at 1100 work if another controller is there? Maybe I'm missing the point here. I have TIPI PEB set at 1200, out of the way of the HFDC. Oh wait, you have TIPI PEB at 1800 now.
  7. No, this emulator was used by TI employees to check emails from home. And anything else enabled by logging in to DNOS or whatever. If a TI employee had a TI-99/4A set up at home, they could get a Hayes 300 baud modem and this software. No other special hardware.
  8. I'm not so sure. But the first page describes a problem, the second page (reply) details two fixed bugs that don't fit the problem. Their code seems correct as far as I can follow it. MOVP %START,TIMER MOVP %IC2S,IOCNTL select & clear INT2 EINT CLR B IDLE BTJO %SETBIT,B,RSYNC8 I2CS EQU >4C The IOCNTL register: CB is saying the IDLE is not released by INT2, which is enabled. Ryoji replies that there was a bug fixed where clear & select might cause illegal exit from IDLE. But CB does that, and is saying it never exits. Ryoji is saying you normally clear the interrupt, then select it again, because there was a bug with simultaneous select and clear. Wherein it might select but NOT clear. So it would fire immediately instead of IDLEing. The second bug is that when an interrupt is NOT enabled, the IDLE state doesn't service the interrupt (as expected) but the IDLE state exits anyway... Still CB calls this a surprising bug, and Ryoji replies with two bugfixes that don't fit CB's description. If it were me, I would guess the bugfix#1 has caused a new bug. I would break the code into two operations. MOVP %IC2S,IOCNTL select & clear INT2 try EQU I2S >44 MOVP %I2C,IOCNTL clear INT2 MOVP %I2S,IOCNTL select INT2 But I guess we'll never know. It seems hard to believe that nobody ever tested the timer on the 70C20A, unless they only tested it the second way (as Ryoji supposes.) When CB says that the AMPL works, he is talking about the CPU simulator on a TM990/601. The 990 simulates the 70C20 and has a ribbon cable to the CC40. P.S. Where diagram above says 11 is a undefined state, elsewhere the book says it is the"microprocessor mode" which makes the full address space external. In this code, it operates with the internal ROM only (state 01 or >40) which maximizes the pins for GPIO.
  9. I haven't done any hardware testing in a month (In fact I had been hospitalized one day.) Zach Freedman says you have to do the boring parts! I picked up last night, testing the 9902 to PC link. The whole system was haywire. A short had developed? Cold solder? VCC was oscillating wildly about 2.5V. Reset stuck low. Maybe the common to PC ground was a disaster? I disconnected the reset switch, tested it in isolation, perfect. Put it back, and went over wire wraps with a magnifying glass. Then I tried to measure VCC on the backplane, slot 7. A solid 5V. Huh? All my logic leads go to the prototype card in slot 8. Hmm... how can VCC differ between slot 7 and 8? What had happened: one of the GND pins broke off my prototype card. x a31................................ a1 b32 b31................................ b1 c32 c31................................ c1 GND VCC The backplane connector is 3x32. From the angle I work at, as I plug the proto card into the backplane, I should see pin a32 going into its socket. b32 and c32 are hard to see. a32 is a convenient reference point to ensure the card is aligned properly. Nope. I had no pin a32, so I had pushed a31 into its socket. All the pins were off by one. VCC did not go into the board. Measuring RESET at c31 was actually measuring GND. The symptom of VCC oscillating wildly, is just like my previous ugly problem. When VCC is not connected to a chip, reading that pin just shows some garbage that leaks through the chips. Last time it was a bad socket--VCC pin of the chip did not make continuity. This time it was just bad alignment. This can't happen with final cards, just the prototype header. A couple hours poking about and things look normal. Onward to the boring parts.
  10. Not waffling at all--it's very interesting to me. I just read about the E-Bus at http://www.powertrancortex.com/hardware/Cortex_1985-09_(Sep).pdf I don't know much about Cortex. Because I was acquainted with N8VM, I used their ECB bus. It's not lovely, since it evolved from Z80 to 8086 and 68020. The 99105 is most similar to the 8086, so I can rest on top of that. Parallel CRU of the 99105 in 00-FF asserts IORQ. The B row of the DIN-41612 has been defined at retrobrewcomputing to provide +8 bits of databus, extended address space, and 8 bits of interrupt code. I'm allowing myself to use SMT in 1.27mm (half the 0.1" TH) I tend to use one 22V10 SPLD per board to knock out 4 TTL chips or so. With that, my first 99105 CPU card fit on a half-Eurocard. So far, I haven't exceeded a 100x100 size, which is the cheapest to get made. Of course, to look nice, it will have to consolidate onto single EuroCard 100x160. I like your video solution. I'm going a different direction with mine, starting with V9958 for compatibility.
  11. I'm interested too. I use xdt99 a lot for TI-99/4A but also the common subset for my TMS99105 EPROM. I think the best bet is to extend xdt99 for the new instructions.
  12. Today is the 20th anniversary of
  13. Thanks for making this! What takes it to the third row?
  14. Nice! I use wire wrap too So this acts like a drive attached to the TI controller? Or do you mean it has its own DSR ROM replaces the need for a controller?
  15. I really enjoyed learning about this graphics chip. I only found the datasheet (30 pages) and databook (same, in 40 pages starting on 171). Those were on bitsavers.org under both Thomson and STMicroelectronics (but SGS folder is older stuff.) Is that a bus with DIN-41612? Did you use the 64 or 96 pin? It looks like a 160x100 Eurocard single. I'm building my 99105-Geneve 2020 using the 96 pin, on the Retrobrewcompting.org ECB backplane.
×
×
  • Create New...