FarmerPotato
-
Content Count
1,465 -
Joined
-
Last visited
Posts posted by FarmerPotato
-
-
If I could get these for $2 a chip, I might want to put 4 of them in Geneve2020.
Otherwise I'm using a $8 CPLD to replace them. Using vintage chips is a goal.
Why four? Well, I'll post that over on my thread, not to hijack this one.
-
If I could get LS610 memory mappers for $2 a chip, I might want to put 4 of them in Geneve2020.
Using vintage chips is a goal. Otherwise I'm using a $8 CPLD to replace them.
Why four?
For starters, the Geneve with 9995 has an 8-bit bus. Reading a word from page registers at >F100 means 2 reads of separate 8-bit registers at >F100,>F101.
Ditto for writing. MDOS assumes fast context switching by doing four MOV to save/restore the registers two at a time.
The 9900 and 99105 read/write 16 bits. Without nasty multiplexing, wait state generating circuits, there's no way to read and write 2 registers in that MOV instruction. Unless you have TWO LS610 chips! Then one holds the odd page number, the other holds the even page number, both are attached to one half of the 16 bit bus. Hooray. This is assuming you want only 8 8K pages.
Using just 8 bits of the registers gives you 256 * 8K = 2MB of address reach.
Problem solved by 2 chips, right?
Now I'm going to assume a SECOND row of LS610 to extend the registers!
The LS610 registers are actually 12 bits. Each register occupies 8 bits in one LS610, wasting 4 bits. I want all those bits! But in the above scheme, every write access would destroy the upper 4 bits (unless you could somehow loop them around. YUCK. You can't count on read-before-write to capture them.)
The SECOND pair of LS610 holds more bits! When read/write at >F100, that chip stays silent, retaining its value. When accessed at a different, word address, the read/write data is multiplexed in a different way, to load one 16-bit even register or one 16-bit odd register.
Picture: 16- bit stitched-up registers spread across four LS610s (wasting 4 bits per chip, and using only 1/4 of the registers in an 8K page scheme)
E1 E2 O1 O2 E2 E1 O2 O1 MOV @F100,R1 * R1 is from E1,O1 MOV @NEWPORT,R1 MOV @NEWPORT+2,R2 * R1 is from E1,E2 * R2 is from O1,O2The upper half being a "base" address for the MDOS instance, that does not change. Four of those bits gives a reach of 32MB, which ought to be inexhaustible.
I use the other bits for status flags--currently I want 3 status bits-- namely read-only memory (ROM), some ports are memory-mapped (SPAMM), and p-box pass thru page (PBPTHP). But there would still be 1 bit left, and 4 wasted, in the upper register!
(I have not thought of a way to get 4K pages in this scheme... wasting half the registers.. actually 75%, so 2K pages could be wished for. But hopeless.)
So that's the scheme using four LS610s. It's pretty crazy!
I will probably just use the CPLD to implement 16 16-bit registers. (I also looked at a 4x4 array of LS670 4x4 register files to do that. Blearg. Might as well use 4 8K SRAMs. Gross.)
I'd like to use real chips, but not if breaks compatibility or gets stupid crazy. Doing it in CPLD allows other magic things to happen, like fast map switching, but I'm not sure if I want to be a purist or not about that.
Why 32MB of address reach?
You can get new 1MB,4MB, or 16MB SIMMs in a pair. 2MB for starters, one MDOS. 8MB enables switching between two or more... or implementing a separate RAMDisk or giving GPL SAMS memory that allocates outside the MDOS space. (Howver , the price difference is $10 for 2MB, $30 for 32MB brand new, or find them used.)
-
2
-
-
The Sandbox is mind-blowing. Imagine if people had known how to exploit this back in the day - commerical "BASIC" cassette programs that get around the bottlenecks in TI BASIC!
99'er magazine reviewers would be stumped at how a program got that performance!
Imagine a FORTH environment that targets the Sandbox loader. FORTH might be a good way to leverage the tiny page size! A word would have to be limited in its compiled size to very tiny. The stacks would be similarly limited. Perhaps static analysis could determine in advance what the required depths would be. (or at least run-time tests.) In the end, a FORTH program that executes from a bare console in BASIC, with mind boggling performance nearly as fast as assembly, certainly faster than GPL or BASIC!
-
3
-
1
-
-
On 6/7/2020 at 11:09 AM, MrTransistor said:Hello everyone. I am Mister Transistor.
I would like to share with you a project that I have been developing.
It is not a nano-peb type of device, and my goal is to allow existing expansion cards in a modern peripheral box.
I have the boards designed and played out, and I am still tweaking the power supply design. After this I will be moving on to systems design, i.e. arranging it in a chassis and prototyping.
Hello!
I've been looking at ways to mount backplane/cards in a common Hammond enclosure ($50-$90) and mATX form factor. I know you and others here want a bigger box (10-16 cards) but I am thinking of a smaller one with 3 cards (plus built-in flex) and a half-height bay.
Another approach I pondered is a 4U server rack. These are expensive though.
On 6/7/2020 at 11:09 AM, MrTransistor said:The whole reason I am writing this is to gauge interest in a device like this, and whether or not I will make more than one.
Further, if there is interest, I would love to hear about your thoughts on improving the design of the original PEB, such as the cable interface being awkward and bulky sticking out of the side of the console. (this is not a problem with my design however, but just an example.)
I have a hunch that a 50-pin SCSI cable would be a better way to connect a flex card to a console boot. Users could pick their own length (within limits).
On 6/7/2020 at 11:09 AM, MrTransistor said:So far, I have a few things that I have decided on. First, miniaturization of the boards. To accomplish this and still retain backwards compatibility with existing cards, I have decided on a modular expansion slot board, where there are 3 per module, and this allows for a smaller box, or expansion of the existing box if so desired. Of course, expansion would require a beefier power supply, so there's that too. This can also be made smaller by sacrificing slots.
You said backwards compatibility plus a miniature size? How would that work? I don't think re-buying all the cards in smaller sizes is in the cards (sorry).. people DO want to use their existing storage controllers, and nobody has made a new floppy controller, plus chips are getting rare. Thierry's IDE as you can see from Shift838's build would be tough to make any smaller... though it has been done for retrobrewcomputers (formerly N8VM).
I'm looking at their DiskIO V3 IDE/floppy card, similar TTL implementation to Thierry's IDE. Its size is 160x100 EuroCard single. Compared to the a P-Box card at 195*150mm, that's about half the PCB area. It uses a SMC 9266 FDC.
-
May's game was SpotShot, or Dragonflyer, by Jim Dramis/Softmachine later published by Databiotics.I hope you all enjoyed this, it's one of my favorite games on the TI. The strategy is tough to figure
out, but now we have a video guide to the game
I didn't know it was possible to get to level 15 but y'all inspired me early on to keep practicing.
I forgot to post my improved scores, but I would still be in 5th place! Congratulations to everybody
who either tested the waters or blew through a dozen levels!fimbulvetr 6210 farmerpotato 34230 globeron 74190 level 12 mizapf 79000 level 15 pixelpedant 102540 level 15 jwild 120880 level 15Next, Jwild picks the game for the month of June.
P.S. why the variability in score at level 15? I consistently get about 5000 per level, with the 10000 bonus after each 3. Is it possible to miss the bonus? Is mizapf playing a different version of the game?
-
1
-
-
1 hour ago, TheBF said:MAIN() runs in about 160 milli-seconds
FMAIN runs in about 4 milli-seconds
How long if you replace 4 * with 2 lshift?
-
1
-
-
What follows is a sort of love letter to Lubbock, TX.
I can't identify with or refute your experience with Lubbock, though it was probably very different for the engineers at TI, which included my father. But I would like to say that Lubbock was a great place to be a kid in the 80s.
The straight grid of streets made it easy to attempt long distance trips on a bike. The streets were not grids in the neighborhoods.
The public schools I went to were excellent (However, I was in honors programs from 3rd grade). Every teacher made an impression that I think about often. One thing stands out above the rigorous math and science: I don't think you could get a finer civics education than we had at my junior high. On one school trip, we went to New Mexico to see the Space Shuttle.
Community theatre, music, and the arts were thriving at the downtown expo center. My family went to several shows per year, standard repertoire that I still rely on knowing. There were recitals at Texas Tech on the big pipe organ, and we heard carillon concerts on the lawn.
I remember a lecture by Grace Hopper at Tech, where she spoke and answered questions about the early history of computing for four hours. Stephen Jay Gould came to Lubbock for the fossils, and later praised its people for "keeping Lubbock an intellectual center in a region with nothing for six hours in every direction."
It was the boom years for video games. Finding the latest ones was a quest to be made on foot and bike. Tech had the biggest arcade around in The Well. Families might have one Atari or one type of computer. You got to experience them all. Also, dumpster diving at TI was a hoot. Everything about TI brought the thrill of arcane knowledge. In the bust years, searching for $1 video games was also a quest.
Radio Shack had real kits, and you could attend several computer club meetings each month.
We had FM99 and Tech's student KUTX. Every time a rock band came through, you knew it from the T-shirts kids wore the next day: Adam Ant, Duran Duran, Quiet Riot, Def Leppard, Motley Crue. Locally, we had Krokus and the Maines Brothers (most appreciated because they had Star Wars on laserdisc. Also they played music.)
Star Wars, Battlestar Galactica, E.T. and Lord of the Rings provided the common myths. It didn't hurt that Lubbock looks exactly like Tatooine! D&D was growing fast, though the churches railed against it.
Yes, churches were everywhere. Then again, Jim Dramis was my Sunday School teacher for a while: the game programmer, of Munch Man and Parsec fame. I kept my guilty secret of pirated games to myself. In addition to alcohol, toys were not sold on Sunday. Blue laws. Our preacher was a theatre major, who randomly appeared in character for sermons (I learned all the prophets, major and minor, this way.) Our family studied Greek through the church. Almost a rarity these days, I went from translating the Bible, onward to Homer (actually, more Dionysius of Halicarnassus), opening up a world of classical knowledge.
Scouting was huge. I participated most years. We camped a lot. Sure, that involved trips to New Mexico, not just the plains area.
I spent my summers in a place most consider infinitely more boring: Wayside TX, outside Canyon, TX, outside Amarillo--which was considered the big city. But Palo Duro Canyon is a breathtaking place. I kept going back because its beauty cast a spell on me.
I grew to love the outside there. Launching rockets in cotton fields. Exploring the playa lakes (clay mud pits for runoff), tunnels under the highways, breaking into tornado shelters, finding the best alleys to ride through (every house had an alley), dumpster diving, running around with all the other kids in the excellent weather (hot summer and occasionally a good snowfall). Helping my brother's team make rafts for the Clearwater Canyon river race. (Still have the belt buckle.)
Lubbock was surrounded by old things: quaint museums of history, the amazing Ranching Heritage Center (think pioneer village). The big Texas Tech museum. And in those places, you not only went to fairs and festivals, but took art classes in the summer, and astronomy at the Spitz Planetarium.
I was at Lubbock's Garden Arts Center frequently. It was the hub for music recitals, weddings, computer fairs, formal dinners, etc (I had no interest in gardening then, other than to explore the labyrinths.)
We had bulletin boards and modems. Lubbock produced Cult of the Dead Cow, the famous hacking group, out of my junior high (I went to them for warez. They consider me a member somehow.)
Lubbock was where I had my first unforgettable crush. The friends I made in grade school, and kept through college, were the truest friends I've ever had.
And, oh yeah, I only saw Prairie Dog Town during the first month in Lubbock. Then I forgot about it.
My family gave up Cupertino, CA for Lubbock, TX, after TI's incentives. Would I have had a better life growing up back there? Who can say?-
6
-
-
Now what happens if you use PAD for WS and 15 unrolled
MOVB * Rx+, *R15...
RT
That would use 18+16+16 words or 100 bytes of PAD.
-
The second 910mp I bought arrived DOA. The menus work but no video. One blown cap inside, in the main board, but replacing that didn’t change anything.
-
1
-
-
My score 34230. I don't think I've seen level 7 until now.
Some things I started to notice in the game:
After level 4, you get a big bonus, then level 5 seems easier. Like how in Munch Man, the Hoono levels come in groups of 3, then the next group starts off easier, then ramps up. Level 4 I think is the twisty little chains of squirted out toothpaste? I suspect Level 5, Bricks in a Wall, only looks easier.
Making the weakness holes bigger: I try to decide if I'm shooting the leading edge or the trailing edge of the weak spot.Do the holes line up again naturally? I guess the pattern repeats at regular intervals, but I'm not sure they align. I'm too busy shooting to observe!
The time spent lasering all the way to the right and off the screen, is time you are not lasering any pixels. Which means more pixels in your way.
You get more points per bug when shooting all the way over to the right. 10 when shot in the column right in front of you, 50 when it's way over to the right. The amounts go up after some levels. I saw 30-70.
Overall, this game is really well designed, as you would expect from Sofmachine. Maybe someone can list out all their games (Qmaze/Jumpy, Barrage?) , as well as prior games of the programmers.. I believe it's the A's of the A list of TI game programmers.
-
1
-
-
Holy cow, I can not get anywhere near jwild's score. I never imagined you could get that far in this game!
On 5/4/2020 at 10:21 PM, jwild said:
120880
Be the Dragonfly
-
On 4/30/2020 at 4:44 AM, Tursi said:\ The concept was to divide the components of audio into separate streams without channel information so that they could take advantage of redundancies. So, there were 3 tone streams, 1 noise stream, 4 volume streams, and 4 "time" streams to manage the whole thing. Each stream was compressed using a simple command byte which could specify a run of up to 64 bytes of either inline data, RLE, a short back reference (offset within a stream) or a long back reference (offset anywhere in the song).
First, I read through this with great interest on friday.
I have some questions about it.
I understand that VGM is a raw capture of the sound chips writes, right?
So once you have it separated into voices, you categorize the tone frequencies into 256 levels? This would seem ok for musical notes, but what happens to portamento? or vibrato? How many steps between tones?
Another thing I am confused about... AY vs PSG. Does PSG always mean SN76489 and not sometimes AY-8910-3? Because for a while, since chiptunes DJs had called them both PSGs, I thought the MSX had the 76489, when it turns out it's the AY-8910-3. The translated Japanese docs call the AY a PSG or an SSG when they're not defining it as "the cascade of the horizontal output."
Is the translation from AY to PSG mostly about changing the commands or do you lose precision?
-
1
-
-
7 hours ago, jwild said:Thank you to Marc Hull for creating this game!
FarmerPotato, would you like to select a new game? Congratulations on that great score.
Any tips for how you did it? I have a feeling you get a lot more points when you eliminate several bugs at one time..
May’s game shall be Spot Shot, or Dragonflyer.
im disappointed that Tex Turbo doesn’t award any more points for combos. And only for killing bugs. I just played it a lot and got in the flow starting at speed 3.
Wait, do you get 100xStarting speed? I got 300 points per bug throughout the game.
Onward to Spot Shot! Good luck to all!
-
3
-
-
28 minutes ago, Tursi said:You know... with the F18A in there, that is actually pretty feasible...
That's thought-provoking... what about using the gpu to do it? To have another sprite track the ghost's location. Without modifying the game code.
Is there any way to flash a gpu program, so that it loads up and starts every time? (feature request idea) An arcade game cabinet with an F18A would have a single purpose.
-
1
-
-
9 minutes ago, D-Type said:Postpone still confuses me as I learned and used Forth 83 for 10 years in the 90s.
From memory, Starting Forth print editions don't mention Postpone, only Compile. (But there is an ansi'fied web & pdf version which has text modified to describe Postpone instead, I think.)
I grabbed STARTING FORTH on Kindle (2017 eBook). POSTPONE is in chapter 11 Defining Words.
I had a paper copy in the 80s and I gave up on compiling words when the syntax didn't match TI FORTH. I use CREATE or <BUILDS >DOES now...
-
1
-
-
I appreciate all the idioms you listed!
I think I got it. You want $OF to execute immediately and compile 4 words. [ ] do not help accomplish that... what I was getting at needs to EVALUATE an expression at run-time. POSTPONE really is the shortest way to accomplish that.
BTW, I see this isn't going to compile either, because the IF isn't balanced.
: $OF OVER =$ IF DROP ;P.S. At the moment I'm using MeCrisp FORTH on BlackIce, which implements some layers of ANS FORTH. I'm testing my 9958 board. It will be a while before I get to a 9900 FORTH again.
-
1
-
-
I think you are all talking about Graphics 1 mode?
In bitmap, I like to arrange the screen table as chars 0:8:16:24 ... 1:9:17:25.
So that I set the VDPWA and stripe down 8 chars in a column, then the next 8, and so on.
Repeat for the other 3rds.
I worked on this when I was trying a rectangle fill.
-
On 4/14/2020 at 11:51 PM, TheBF said:This got me wondering what would it take to add this to Camel99 Forth.
Not bad for a "low level" language.
\ string case statement NEEDS DIM FROM DSK1.STRINGS NEEDS CASE FROM DSK1.CASE : $OF ( -- ) POSTPONE OVER POSTPONE =$ POSTPONE IF POSTPONE DROP ; IMMEDIATE : TEST ( $ -- ) CASE " APPLE" $OF CR ." Granny Smith" ENDOF " PEAR" $OF CR ." Barlett" ENDOF " GRAPE" $OF CR ." Concord" ENDOF CR ." Unknown fruit" ENDCASE ;What is the difference between $OF and:
: $OF OVER =$ IF DROP ;or
: $OF [ OVER =$ IF DROP ] ; IMMEDIATEI'm trying to understand POSTPONE and IMMEDIATE and [ ] from Starting FORTH. One of the chapters I could not understand at all when I was younger.
On 4/14/2020 at 11:51 PM, TheBF said: -
1 hour ago, senior_falcon said:My son and his wife are expecting their first child in September. They requested that I build them a baby changing table/dresser. So I have been busy with that instead of retrocomputing. Below are pictures of the result. Now I can get back to working on XB 2.8 G.E.M.
Wow, that is a fine-looking piece of furniture you made. I really admire it.
The changing area on top, is that a separate piece?
-
4 hours ago, Tursi said:Yes, how that's generated I do understand, and I even understood it well enough to confirm that mapping landed data at the expected address in 16k space on hardware.
But on a normal memory chip, as long as you read and write using the same address lines, who cares how they are scrambled?
So why doesn't it just work anyway? All the tables are located in the first 4k (well, except the sprite descriptor table, but that's empty at startup...)
Are we sure it didn't work on hardware? Cause I'm wondering if I should change the Classic99 VDP drawing code to respect the 4k bit too...
right now it doesn't and that feels like an oversight.
I'm stumped too. I would have thought it behaves like you said.
On a 16K 4116, there are 7 bits of row and 7 bits of col. A 4K 4027 has 6 bits of row and 6 bits of col. In 4K mode, the 9918 outputs a 0 in the MSB because that's chip enable for the 4027. So if 4116s are connected and 4K mode is active, the 7th and 14th bits of the address are lowered to 0.
This would make a pattern of skipping every other 64 bytes of the 16K RAM, and then hitting the bottom half again.
Then there is DRAM refresh. If the 9918 is in 4K mode, it doesn't refresh half the rows (because 6 bit row counter.) It does refresh the rows you are using... I don't understand what else might be going on inside the DRAM.
There's something weird in the V9938 book too. The appendix tries to explain how to connect 16K chips with 8-bit rows (8,6 not 7,7), so that they refresh, though they lose half the rows. It seems that they try to guarantee that the MSbit gets toggled, while a LSbit gets ignored. The implication is that it matters.
-
1
-
-
On 1/24/2020 at 1:44 PM, pnr2015 said:I think you are maybe over-analyzing it: connecting CLKOUT to /PHI3 will likely work up to 4MHz. Connecting CLKOUT divided by two to /PHI3 will work up to 6MHz. Use the falling edge of CLKOUT to clock the divider to get phases right.
1. I think that the address lines may not yet be stable at the start of ALATCH, but certainly will be by the end of it, i.e. you may have a CE glitch during ALATCH. Normally this should not matter, as the actual fetch or write happens later in the cycle.
2. I think for the 9901 the PHI3 duty cycle does not matter. PHI3 appears to have only two uses: to drive the internal counter and to synchronize the interrupt circuit. The data sheet only says that the pulse width is *minimum* 45ns, it could be wider. Looking at the 99000 and 9901 data sheets, using CLKOUT for PHI3 should work for both purposes.
3. The 9901 output bits are driven by the falling edge of CRUCLK, not by PHI3; the extra PHI3 cycle does not matter I think. The input bits are read on the rising edge of /RD, again PHI3 does not matter. With the automatic wait state there is plenty access time, even at 6MHz.
To be sure, set up a test circuit on Stuart's 99000 board. I've glued a small strip of solder less breadboard in one corner for such experiments, but I don't have a 9901 at hand to verify my above views.
Belated thanks for your answers! I stopped over-analyzing it and went with your information. I re-read the 9901 datasheet.
1. Worried about a CE glitch. I will make ALATCH a low-enable to any '138 address space decoder. That will make devices get off A0/D0/CRUIN when a new A0 is being output by the CPU.
on p.98 of the 99110 datasheet, I see ALATCH high is twH3 = 30 ns (from 166/4-10). I need to check that the '138 propogation and 9901 CE* disable times fit.
I don't have hardware to test on yet. But I'm building a 4-slot backplane with one breadboard, where my CRU module will be a plug-in card. INTREQ* has a pull-up at the CPU, and INTREQ* and IC0-IC3 will be reserved for the CRU card in slot 1. Each slot can have its own interrupt line.
-
2
-
-
Progress with V9958 board bring-up:
RESET fixed, VWTR works, RGB out shows a 15 kHz pattern, and RGB levels change with VR#7 background color. Yay!
Memory tests for 16K still pass. Setting R#14 , the 3 upper bits, not so much. I made sure the 16/64K bit was set.
With all reads/writes working, I sped up memory access time. I'll aggressively move it to the V9958 limits.
VDPSTA reports 9F: the INT bit, no 5th sprite bit, but Fifth Sprite#31. So far so good.
Issues
INT is stuck low. It is enabled by IE0 in VR#1 (same as 9918) and I tried an endless loop to read VDPSTA (clears INT when read). INT stays low.
WAIT* is stuck low (V9958 feature, aka READY). It is enabled by bit $04 of VR#25.
Bug Fix: RESET
The 9958 datasheet said "RESET low pulse minimum width 10 ms"
I soldered in a 1 Mohm and 1 uF cap for the R-C on the RESET switch. My RESET pulse was, dutifully, 10 ms of low. After rising to around 1.5V, the 50 uA current charging the cap was diverted into the chip input. Stuck there! Makes sense now... I changed the resistor to 1K for a RESET low pulse of 10 us. The 10 ms is certainly a typo. I could not find the value in the 9938 book, but it is 1 us for the 9918. Fixed.
Next up
Going back to work on analog RGB and composite video.
-
6
-
-
Now for the status of the V9958 board bring-up:
I found some bugs in the PCB. Fortunately I could work around them in software (mixed up pins etc). I had to unscramble and scramble the pins of all 16 I/O lines (that was a surprise) and I had the '138 address inputs wired backwards.
Verified that vsbw and vsbr code drives the V9958 pins correctly. Checked timing and pulse widths.
Still no RGB out. WAIT and INT are not right. I enabled these things in VR#0, VR#1, VR#25. It must be that vwtr is unsuccessful.
Memory test of 0-3FFF is a success. Setting the address bank in VR#14 does not switch banks. Ergo, vwtr is broken.
I spent hours checking csw-csr timings (page 121-124 in V9938 book). There are some big gaps of 2us and 8us that must be met on the V9938, and I put those in.
So, what I have is a set of FORTH words for vdpinit, vsbr, vsbw, vwtr (broken), setting graphics modes, and some memory tests. These run in the FPGA MeCrisp FORTH, typing on the high-speed serial port.
I kept a list of bugs and changes, for PCB rev2.
I consider it a good weekend, since the memory tests pass, and I know a lot more about the V9958.
-Erik
-
4
-
-
3 hours ago, mizapf said:In my opinion, having a kernel/user mode selection should also mean to prevent any direct access to devices, even if that means it will slow down things. This also includes making LIMI 0 illegal for user processes. The XOPs are our system calls, and they should be mandatory for access.
But there could be a compatibility mode for older programs that directly access devices. (Yes, I also wrote such programs.) I think you can permanently stay in supervisor mode if you do not set the bit in the status register using LST or RTWP.
That's interesting, that there could be a compatibility mode, plus a strict MDOS mode. I'll think that through.
Aside from whether strict access to ports is imposed: (I'm just thinking of VDP)
Any XOPs, interrupts, and LIMI instruction will always trap into Supervisor control first. Supervisor can ignore a LIMI from GPL/MDOS as needed. (If it doesn't want GPL to change the interrupt mask) The real INT1 to the real 9901 traps to the 64K EPROM, and lets the supervisor do what it wants to first. Then the supervisor branches to the MDOS/GPL INT1 vector.
Privileged(supervisor) mode runs in a plain 64K space with MS=0. There is 32K of EPROM and 32K of RAM (maybe some simple paging, if I need that.) (LDS and LDD can read/write to/from any page in the memory mapper, relying on the ST8 Map Select bit flipping.)
I hadn't considered running anything outside that 64K as supervisor. But I was confused about the ST7 Privilege and ST8 Map Select bits, thinking they were the same thing. I see now that the Supervisor can RTWP with PRV still active(0) and MS set. This would return into the user memory map with privileged mode.
Back to VDP:
I guess "strict mode" could detect access to a port (VDP etc) and drop to the debugger; however, letting it go ahead might be perfectly fine! Unless you wanted some effect like, an MDOS program is left running but its screen is hidden by something else... I don't think this would end well (how would it be told to re-draw itself again?)
Double-buffering all the VDP accesses in a shadow VDP is not really feasible! Maybe just for text mode? Or, it's more likely you would want to freeze one GPL environment (with VRAM saved to main memory), switch to MDOS, then switch back. Another option is to use two VDPs across the two environments.
All this memory-mapping of ports is configured by bits in the FPGA (and memory mapper page registers). If the bits stand for a certain mode, a memory cycle goes to some i/o register, if not, it is just memory access.
It might even be possible to filter some access in simple ways.. like not letting a user-space program turn off the IE0 bit in VR#0 (user programs can't disable the VDP interrupt) (this is actually messy because the sequence is 00 87 to VDPWA. After recognizing a >80 to VDPWA , it's too late to catch the previous byte. Maybe the fpga could just queue up a second register write to put the IE0 bit back. Not going to worry about that for now. Maybe the Supervisor doesn't care what you do with VDP INT1, if it has no use for a 60 Hz interrupt.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
What if? Designing "Geneve 2020". Cool 3D views!
in TI-99/4A Development
Posted
Since there was no status update in May:
Status June 10
The CPU board is arriving from SEEED next Monday. Then it will be time to assemble and debug it. I will test it with a NOP (>1000) hard wired, called "free running."
The BIOS memory card is routed, but not sent, pending some QA. This will hold the initial software in EPROMs and provide some RAM.
The CRU/Serial 9901/9902 card must be started over. It was once integrated on the CPU card.
The 8-slot backplane is here. Everything will be based on 160x100mm Eurocard standard, Cards can be 100x100mm if you like. In fact, the backplane is an ECB-Kontron compatible backplane! As a result, I anticipate the ECB Disk IO V3 off-the-shelf will provide DSDD floppy and IDE access, but require re-writing drivers (The supplied driver is in Z80.)
Some parts of the 8-slot enclosure is here. It is going to be super classy, but cost $150 including backplane. Optionally, you can put the naked backplane into a PC tower. A 12-slot backplane and enclosure is possible, or a 4-slot (I have to combine some cards to make that viable).
I am going to give a PCB order to Aisler - they will make one for about $40 shipped to me, in US or Germany, not much more than $30 with shipping from China like SEEED Studio. Or $80 for a 10x10cm from OSHPark, yikes.
Features implemented:
The 16-bit bus and 8-bit peripheral bus (VDP, sound, Pbox etc) are unified on one backplane. Access to 8-bit cards will be direct when memory-mapped ports are enabled, and always possible through CRU byte-or-word-parallel (two cycles vs one for memory mapped).
The CPU card drives 15-bit address and 16-bit data lines and all other CPU outputs to the bus. It adds several useful signals like IO parallel and serial, and generates some ECB specific signals for compatibility with Z80 cards.
The CPU card supports external Macrostore and attached processor interface (think floating point coprocessor.) It supports external RESET and NMI buttons.
The BIOS card decodes Macrostore access (integrated into the Page 0 EPROM space, not a separate page.) It supports supervisor and user memory spaces. It supports one 16K ROM page 0 and one 16K RAM page 0 always present in supervisor mode, and bank switches additional 16K pages of ROM and RAM (currently 8 pages of ROM, 16 pages of RAM.) It also has nice LEDs.
Not implemented
Plans for the DRAM card amd memory-mapping are wired into the CPU and BIOS cards.. the DRAM card will have the memory-mapper, making a 32MB user space.
VDP is still sitting on my desk. It generates 15kHz different RGB screen colors.. But I have not got it to sync with the Acer monitor yet. It will require a revision or a bus adaptor to use.
FPGA is back to the drawing board. However, it's becoming less necessary, as more functions are implemented in real chips. The bring-up system will run software without it. However, the SD card filesystem is in my FPGA so...
I have found a ready-made ECB Disk IO V3 floppy and IDE controller. It is uPD765 compatible (IBM 360K). It's not too different from Thierry's IDE, but drivers will have to be written.