Sunday 9 July 2017

SUPER STFM MOTHERBOARD PROJECT

Myself and Rodolphe Pineau have long since talked about creating a new motherboard but felt it was a lot of work to which would be very time consuming and costly. Though I have re-visited that idea recently and talked about cloning the STFM motherboard.

Now the first thing people will say, "why not STE", "why not Falcon", "why not Falcon with 060" etc etc. Well, time, cost, and being realistic.

While other "clones" go down the 040,060 route or "emulate" the Atari ST, while a new CPU with all its speed and features is nice, without new software to use all the new features its a bit of a waste. As most software is plain 68000, then a machine should at least run that software without issues.  I am not saying I am against new features,  I'm all for them, though not at the expense of breaking compatibility with original 68000 software.

My philosophy is , as all the software and games are 68000 based then that should be the CPU to keep.  A machine which runs all legacy software just like the real thing.  I want the fastest 68000 system possible. True, some things will break with demos and timing dependent code, though like with all my boosters, you can turn off the speed boost to get back to 100% stock state.  So people get the best of both worlds.

Firstly creating a new motherboard is not easy, especially when trying to create a whole new architecture. Not only that, parts are hard to find, impossible to solder and we don't want to create something which will become obsolete easily.

My aim for this project is to create a STFM clone only using "through hole" parts. This means people can solder it themselves as there are no SMT parts to worry about.  This also makes future modding a whole lot easier.

One problem with the STE is the large SMT IC MMU/GLUE logic.  Making changes to the STE circuit is near impossible in some ways.  The STFM however, GLUE and MMU are separately so we are able to overclock the MMU for example for higher ST-RAM speeds.  So because of this, the STE isn't a good machine to clone.  I want to build a machine where parts are relatively easy to obtain and solder.

Of course the STE has the Audio DAC circuit and the jag ports etc. Well those could be added on as a expansion or on future motherboard revisions.  My goal here is to develop a open source platform to the STFM world and let people build on what ever they want.

The board in mind is the board I developed most of my upgrades for the C070789.  One thing which has become apparent over the years is that the STFM has been updated with all my kits which basically takes over a lot of the motherboard already.   Adding up the "cost" of buying all the kits is likely going to be a reasonable sum by itself. Plus all the assembly work etc.

Building boosters has become a nightmare simply due to things like my V2.2 booster needing a 6 layer board in order to keep the PCB size small enough to fit in the original case. If the motherboard had a fast-rom and fast 68000 to start with, then the cost to add a booster wouldn't be much more than adding in the extra PLD logic.  Plus no problems with fitting, saves endless hours of routing PCBs in a small area. Multiply that idea with several kits and you get the idea..

We mostly have 6 chip or 2 chips TOS. The first upgrade which normally gets done is to convert to a PLCC ROM which can actually hold TOS102 and TOS104 normally. So the new motherboard would simply have a PLCC ROM. The ROM is easy to change and update and can run at 32MHz.

Similar with the "mars bar" CPU.  The DIP maxes out at about 24MHz. Its power hungry, huge and the HC PLCC version is much better.  Its lower power, more stable, can run at 32MHz.  Having this CPU and ROM as "stock" means adding a 32MHz booster wouldn't be much more than adding in a small GAL / PLD IC.

Similar with 1.44MB floppy drives. Always having to remove the WD1772 just to add a little logic. Similar with adding RAM expansions, never easy. Overall, trying to continue in this direction just isn't realistic anymore.

Not only that,  We have PCB layout issues contributing to the DMA issues and god knows what else. It all needs fixing properly.  The only way is to just create a new motherboard, one that is more user friendly and basically has various improvements including adding on some expansion ports!

Its the same old story, people want IDE, people want fast-ram, RTC, flash rom, 030 CPU, this and that etc. Well, people will ask why not build all this into the new board ? Well , time and cost. Do people want a board next year or in 5 years time and costing a lot more ?   Everyone wants something different. So building a basic machine which the possibility to expand to whatever people want is the best thing to do.

I also want to keep to the original schematics as much as possible. I don't want to build in huge amounts of changes and over complicate it. I want a simple as possible STFM design where people can develop their own addons and use the expansion connectors.   The expansion ports will probably follow similar lines to the falcon's expansion connectors. I can speculate that 50% of the STFM area will be free for adding expansion ports. Its possbile 3 or 4 could be added inside for example.  There will be larger areas to add future boosters easier like adding a 030 CPU addon card.

Once the STFM has a PLCC ROM and CPU, it frees up a huge area of the PCB already.  Similar with the RAM, 2 small DRAM IC's like my MMU kit can give 4MB. So the whole area under the PSU would become free real-estate.

While on the subject of RAM. I did first think of adding on a 4MB 72pin simms. Though its not really future proof. With simms becoming harder to find along with the socket, its not a good idea.  The alternative is the 2 DRAM's, but they are SMT. I don't want to do that. I could produce a RAM card , but I don't want to create myself even more work in the future and don't want people to be limited to only buying my RAM card.

After some thought, The idea of using a RAM card like the falcon came to mind. I mean lots of 1MB or 4MB cards are around for almost pennies.  It also makes it more future proof as alternative RAM cards can be made if needs be. It also means the MMU and ROM can likely go under the RAM card. This will also save a lot of PCB space and also make the PCB routing a whole lot easier.

The next main obstacle I saw was the shifter area. So many parts. A lot of them are not needed if the RF box is not used.  Also a lot of the circuit is generating the 32MHz clock which can be done with a simple oscillator chip.   The only thing which is left is the RGB drives. Myself and Rodolphe did look into adding in a video DAC there. Though in the end, we decided its not a good idea.  In anycase, the MEGA ST shifter circuit would be used. Its simple, only really needs the Shifter and the RGB drivers. So a lot of parts wouldn't be needed, and saves a fair chunk of PCB space also.

IC's become obsolete, generally get smaller and turn into SMT parts so small they are just impossible to solder by hand.  With the simple RGB transistor drives the STFM has, its only a few transistors and resistors. It keeps thing simple and we don't have to worry about parts becoming obsolete anytime soon.  I do also think the circuit can be done with less parts like on the MEGA ST.  So this in itself keeps parts count down and increases the free space on the motherboard a lot.

A lot of the ST parts are generic. Though things like the MMU, GLUE, SHIFTER, DMA are of course not. Though these are obtainable as spares sold around the Internet, or scrap motherboards etc.

There are a lot of "classic" parts, resistors , caps, TTL chips etc.  For the moment they will all be re-created. Though its possible all the TTL chips could be mashed up into 1 single PLD saving parts count and PCB space in the future.  Its possible a few parts of the circuit could be tweaked to save parts of PCB space. Though thats wok for another time..

I would have hoped someone by now would have helped create some new FPGA clones for the chips.  I would really like a faster MMU using SRAM.  ST-RAM is the main bottleneck for speed. Though overclocking the MMU is the only option at the moment.  It is also limited to 4MB.  I'm sure tweaks could be done to give 14MB ST-RAM like the Falcon. If it was using SRAM then using alt-ram would simply not be needed anymore.

I know there is code for MiST and Suska etc, though I know nothing about FPGA and not really sure those FPGA clones will work on a actual ST machine. Even so, someone would have to develop such things as I just do not have time to do everything myself.

I would think a lot of the "work" the GLUE does is ROM decoding for example. Though in FPGA it would be easy to add in TOS206 support. Though such IC's would need to be 100% cycle compatible to emulate the real ST timings. I don't want to create a ST which breaks anything at all.

Of course any boosters will break a lot of demos which need cycle accurate timings. Though that is the price we pay for speed.  My concern here is, if everything went into FPGA, then we basically end up with a MiST anyway. So to a point it would become pointless to create a FPGA based machine as it already exists.

So my aim is to emulate the ST 100%. The only way I see that currently is by using the original ST chipsets.  AFAIK, MiST isn't cycle accurate and may have various issue with software. I want to keep the ST design "original". If FPGA can take over a IC 100% cycle accurate then I am all for that.

There are probably a lot of tweaks which can be done. Though we want to get something built now rather than spending the next 5-10 years tweaking everything to death. New boards can be done in the future anyway if needs be.  Everything can be in a socket, or even have breakout headers for each IC for future tweaks. So if someone wanted to develop a new GLUE or MMU, then it could simply "plug in" the motherboard.  If something went into production, then people using the new Super ST motherboard could simply pop out the old IC and plug in the new FPGA based board.

For starters I want to create the STFM schematic over to Eagle format. Once verified the layout of the PCB needs to be done.  It will take some time to make sure all the connectors and such match the original PCB.  Once down, that schematic will likely be released but not routed.  That would be the "clone" of the STFM board.  Basic changes will be done, such as ROM and CPU PLCC packages but not much else to start with.

The whole design would be open source.  A lot of "clones" and addons are not and re-creating upgrades over and over is just pointless and a annoying waste of time. As many also are aware, there are so many revisions of the ST motherboard, that its just impossible to create upgrades which physically fit on every revision. So likely around 80% of people around the world cannot even fit my upgrades.

The upgrades which do sell are less than 10 typically in the first year.  Spending huge amounts of time on projects which hardly ever sell just isn't a good useage of my time.  Don't get me wrong, I'm not in it to make profit out of this, but as I have said many times before, spending months of work on something which only 5-10

As mentioned before, a lot of my upgrades are for the C070789 board. There are several revisions of motherboard and all those people are limited to what upgrades I produce which fit. Its just not realistic time or cost wise to develop the same addon 20 times for fit each revision. Some boards still cannot be upgraded due to SMT MMU etc.

There is also the fact that PSU's are failing where I offer alternatives, but motherboards are failing also. Take for example the video faults I have documented due to caps failing in the video circuit.  Every electrolytic is 30 years old now. Servicing such boards is becoming a small nightmare. Again with so many revisions, supplying "servicing kits" for various things is becoming a huge investment, where I do not have unlimited funds, or time or space to go though every issue on every motherboard. A new motherboard would use ceramics as much as possible to prevent similar issues from developing in the future.


The new motherboard will likely cost a lot to prototype.  Several prototypes may need to be done.  As the cost could be high per board (could even be around £200 a pop).  Though by the time the buyer brought all the service kits and upgrades, then the cost probably wouldn't be much different anyway.

My aim is to re-use STFM IC's, possibly also a lot of the connectors and create a STFM "clone" which is basically updated.  The STFM clone will be 100% compatible with a real STFM.

Though as mentioned before, adding in boosters or other upgrades can be done easily. Also like my V2 booster, it holds TOS206, TOS104, and can be switched on or off for stock speeds or turbo speeds.  The advantage is that it wouldn't any longer need the booster PCB, it would be as simply as plugging in a extra GAL / PLD to enable those features.


The motherboard will likely get designed and made open source. Though my concern is here, again, is the end cost of the motherboard and people being able to assemble them.  Overall, if someone purchased a STFM motherboard and fitted all my kits, the cost of the new motherboard probably wouldn't be much different anyway.


I will likely have to set up a kickstarter campaign to fund this in due time.  Then it will be up to the Atari community if this "Super ST" becomes a reality or not.

17 comments:

  1. Sounds like a good plan to me :)

    ReplyDelete
  2. I think this is a very brave endeavour Chris, it would be great to see it come to fruition.

    ReplyDelete
  3. I think this is a good idea, the orig. Atari boards won't last forever. New boards, as many modern plug in replacements as possible and that's a whole new few generation of fast ST's sorted built to a standard so no more 10 versions of 1 upgrade needed, happy :)

    ReplyDelete
  4. Yeah. Having a standard layout for a upgrade board will just make life a while lot easier long term.

    It does actually beg the question of if its worth while producing a lot of upgrades which I sell in my store now. Not much really sells overall. Things sell way to slow to warrant new batches of a lot of stuff being done.

    I think mostly people just want to get the original machine working as nice as possible. Those who have the time and cash and want the best of everything will have to invest in the new motherboard.

    ReplyDelete
  5. If you need help with routing on eagle, I will glad to help.

    Edu.

    ReplyDelete
  6. Thanks, I am doing the routing myself as I am doing changes to the circuit as well. So its not so simple to copy. But I will need people to check my schematic against the STFM one to see if everything basically looks correct.

    A lot of things are hard to read, so going back to the ST pdf as its much clearer, but circuit is not the same and neither are part numbers. So its taking a lot longer to create than I first thought.

    ReplyDelete
  7. Sounds great. I'll join the Kickstarter campaign. Looking forward for nice rewards and of course a new motherboard!

    ReplyDelete
  8. If you need an inspiration... https://icomp.de/shop-icomp/en/shop/product/c64-reloaded-mk2.html ;)

    ReplyDelete
  9. Cool. I've seen various motherboard remakes like that for various platforms. It's about time the Atari ST had one.

    ReplyDelete
  10. Hmm, how modifiable would the general design be to upgrade the core components, and essentially make the bridge machine Atari should have come out with between the STe and Falcon (or in place of the STe, as a sort of Amiga 3000/Mac II type affair...)? I've long since had the rudiments of such a specification in my head, mostly the kind of incremental, backwards compatible upgrades we never saw in reality. A bit like the "Spectrum Next" and all that.

    EG
    (ok, I just found we have a deeply anachronistic 4096 character limit, on trying to post the whole thing, so this is going to be a bit of a chop-up job, especially as the largest I can extend the edit window to is about 64 characters by 16 lines like an ancient Altair terminal)

    > a higher clocked 68010 (it opens up just a few extra software possibilities, like proper VM multitasking, as well as being slightly more cycle efficient, and the minor incompatibilities can usually be patched - or, in a modern recreation, there could just be a dual core in the FPGA or two physical processors) or even an 020 running in 16-bit-bus mode
    > dual memory bus model closer to that of the TT or Amiga with a certain amount dedicated to the AV system and everything else being CPU-only, with base models only having the fixed (*maybe* limited-upgradeability like Amiga ChipRAM?) factory-installed amount available...
    > maximum onboard extended to at least 10mb (one main bank having its "128k" or "0k" option replaced with "8M") or as close to 16 as possible (two 8Ms, minus the existing "holes", minus whatever's dedicated to AV)
    > Upgraded soundchip to something in the Yamaha OPN series. These retain full 2149 compatibility, including the IO ports, but add FM and optionally (AD)PCM channels on top. They were used to great effect in various, mostly Japan-only computers and consoles, and give an overall result that's most of the way to an early 90s Soundblaster card, especially if bolstered by a couple of STe-type plain PCM DMA channels. Like, you have three'n'a bit channels of PSG, three or six (at least) of FM, one to three PCMs... you can do a lot with that, all happening at once, without even getting on to CPU pre-mixing of PCM sounds. Some offer stereo right out of the gate too. Better yet, the (AD)PCM capable ones inherently support *recording*, in mono at the same bitdepth (including ADPCM encoding where relevant), at the same rate as replay for PCM (and about half the rate for hardware ADPCM encoding - of course, you could record PCM then encode it using the CPU instead)
    > better DMA audio channels... that is, allowing more than just the four STe output frequencies, so a properly tuned note can be played without CPU interference or storing tables with a sample for each note etc. This would be a pretty simple change... also allowing variable slots so the video system could use any bandwidth not expressly claimed by the audio, so slightly higher video modes could be achieved at the expense of some (or all) DMA audio quality. As well as being able to go a little higher than the STe data rate, in order to e.g. feed the third PCM channel in the Yamaha chip without having to use PIO, or integrate its own separate DMA abilities into the system.

    (is this short enough yet? pt2 and probably 3 & 4 to come given how much I've deleted so far. What's 4096 divided by 64 again?)

    ReplyDelete
    Replies
    1. (continuing)
      > improved video modes by increasing shifter palette registers and depth (eg 64 entries of 15 bits), and allowing altered AV-memory-bus contention ratios and different master clock dividers (and maybe additional input crystal(s)), as well as making use of the increased bus speed of course. Possibly even a small SRAM (2-port?) buffer to extend the colour depth/rez by allowing reads into it at regular speed during blanking periods, but faster reading-out during active periods. Goal of course to hit VGA, or at least 640x400 rez, in 16 colours, for a Windows PC/Mac II/NEC PC98 esque appearance on Multisync monitors, as well as much more colourful low-rez modes; 256 colours would be nice, but we could probably settle for 64 at 320x224/320x272 (and a slightly reduced pixel clock for overscan) with shadow/highlight effects or the like, giving a Megadrive-like end result.
      > As part of that, the ability to use more types of monitors. VGA would be an obvious one, but general Multisync compatibility is a no-brainer and entirely appropriate for the time, allowing use of both 60/70Hz VGA modes, 72Hz hi-rez, as well as higher resolutions with similar or reduced refresh (if you have a long persistence monitor anyway), lower resolutions with same or higher refresh, etc. As well as TTL colour output (with the obviously more restricted master palette), for hi-rez colour on a budget. Lower Hsyncs and *maybe* Vsyncs would be useful or even necessary to set some of the higher resolution/colour depth combinations anyway, otherwise there just isn't enough data bandwidth. For example the stock ST would be just about capable of running in 2bpp mode on an IBM MDA or EGA monitor or at that rate on a Multisync, maybe even a 25kHz type at a push (certain PC clones, a whole load of Japanese systems like the NECs, Fujitsus and Sharps), and a straight clock-doubled (or 10ish MHz clock, 2:1 contention) system could manage 4bpp, but doing the same on VGA, let alone at Mono rate, would be a step too far... though we could probably manage 3bpp, or drop from 640 to 480 horizontal pixels. (And 480 at 3bpp is an idea for a more-or-less 80-column ANSI compatible terminal mode using entirely stock bus speed and contention on a 15kHz monitor, only needing a slight boost to reach 4bpp)... either way up, only having 15kHz colour or 1-bit-TTL monochrome 35kHz hi-rez, at the turn of the 90s, would be needlessly limited. 31+kHz analogue colour was the new hotness and Atari could have surfed that wave if they'd tried...
      > Maybe some kind of sprite engine to back up the Blitter. And a turbocharged Blitter anyway of course. Particularly one that can DMA and thus make use of non-CPU access slots in the blanking periods, in non-buffered video modes. The spriter would have to do that anyway after all. Probably best to combine the two.
      > Also twiddling the DMA (and MFP) to be able to share the video channel, or what would have been CPU slots accessing one or other memory area when the CPU is actually accessing the other. And more particularly the dead time during the CPU memory access cycle which in the original ST was always taken by the shifter, but in one with a non-AV memory bank might otherwise be entirely wasted.
      > RTC of course

      (and break...)

      Delete
    2. (continue 2... and man, the whitespace really doesn't work well in this blogger theme does it... nor the line width)

      > joyports in a sensible place. Digital ones both being extended to at least 2-button, if not a console-like multiple button serial readout. Preferably just replaced, in the thought experiment, with a pair of 15-pins, and bundle in a couple of adaptors that break out each to a pair of 9-pins so you could use two analogue inputs/jagpads, one plus two trad digital sticks, or four sticks, without need of printer adaptors etc (with some kind of automatic overlap-mapping of those inputs to the old joy1/mouse-and-joy0/printer port pins, but retaining the 2+ button capability somehow). Nowadays of course, just put USBs on it and let a microcontroller translate the input from whatever's plugged in to something the CPU can understand.
      > separate keyboard, with Mac-like dedicated 9pin socket on it for the mouse. Connecting to a nice Mega or even Microbox style slimline case but with a little bit of internal expansion options. Maybe have an official swap-on tall case cover to make room for a Megabus/VME bus riser and/or splitter card and internal cardcage, without having to have a specific large-box expandable model.
      > more ROM space... back in the day it might have been the case of leaving sockets for additional chips with OS extensions or the like, but now I guess we'd just have some bank-switchable flash as per your 8mb upgrade board and load it up as needed.
      > Better HDD provision of course, though making a period appropriate interface would be a bit of a curate's egg these days. Just provide some kind of internal storage and have done with it.
      > Better cartridge port is also something it'd have been nice to see back in the day, maybe extended ISA style with a wider port featuring a secondary connector only newer carts would connect to (and would be placed to not block older ones), carrying additional address and control pins (including R/W), and maybe leaving space for an extra 16 data lines in future... but kinda irrelevant for an "ST Next" unless anyone was to start making retro game carts for it. It'd have been good for games to load faster and take better advantage of the extended graphics and sound without necessarily needing faster disks or more RAM though, and could have been (along with the replaced joyports and detachable keyboard) the basis for an ST based console that was more pragmatic, practical, easier/cheaper to manufacture, and crucially actually made it to market and able to compete with the Megadrive and NES (maybe not SNES) if nothing else.
      > (imaginary period version) - make the parallel port faster and bidirectional, ramp the serial port speed right up with a proper UART, maybe do similar with the MIDIs so they can also be used for low cost token-ring / Appletalk style networking (and possibly quietly introduce a "gen 2" MIDI signalling speed as a side effect, getting rid of the problem of latency and multiple simultaneous notes causing timing jitter), maybe even just add specific networking (upgrade)ability, upgrade the ASCI to a proper (but backward compatible) SCSI (as there's many more things that's useful for than just HDDs)... oh, and HD floppies, natch. Maybe, eventually, it could have had an internal CDROM...
      (on an actual modern version, most of that stuff would either be irrelevant, or emulated via USB/Ethernet ports/wifi chips or the like anyway)

      [arse. can't quite fit the last bit in. it's essentially an epilogue anyway so may as well go in a separate post]

      Delete
    3. (continue 3 ... insert coin)

      Like, just having a regular straight-compatible version that happens to be able to run at 32+MHz and use a larger amount of memory is a perfectly good start and would satisfy most people. But one of the things about the Next was to sort of make the Spectrum successor that Sinclair never got round to (though you could make arguments for both the Amstrad CPC and the Sam Coupe sort of counting, one wasn't directly compatible and the other was a mistimed and undersupported failure with a lopsided spec sheet) and see what the longtime fans and remaining hardcore programmers could brew up with the same general operating environment and ethos, but a few more clock cycles, storage bytes and pixels / colours / hardware video acceleration features to play with on top of the existing well-work programming hacks. The Amiga crowd have had plenty of similar all-round boosted models to play with both official and otherwise down the years, what with Commodore being a bit (but only a bit) better at incremental development and various revival projects having risen and fallen over the last 20-odd years. The PC brigade haven't really had to do any work at all. What's missing from this ecosystem is a similarly super-fied ST. Atari failed at it, despite showing off an "EST" protoype that ticked several of the boxes only a couple of years after the ST's own launch and some time before the STe, but then seemed to get distracted by the Transputer project and did a strange job of first downgrading the idea into the Mega (and somewhat later, Mega STe) and then massively overupgrading into the TT... never actually producing that middle ground, with the closest release being the FX1/Sparrow dev machine that then evolved into the Falcon... could be we need a homebrew hack-up instead. Which is sort of in the whole 16-bit Atari spirit after all, as embodied by your good self...

      Delete
    4. FWIW on the video mode front, it's a little annoying even that Atari never even did something as simple as adding adjustable overscan, or additional dividers for the pixel clock and timing cycle modes for the shifter, along with either extra palette registers or some kind of trick Amiga Halfbrite/Megadrive S+L/NES tinting blanket modification modes.

      EG if you retained only 16 entries, in 32-colour mode you could choose to have the top bit either invert the output, or halve it (or, possibly, add/subtract a certain amount on each channel; advanced mode would pick offer eight options for what combinations of channels would be affected, including of course "none at all" for easy, low CPU, rasterable palette-swap-like effects), and in 64-colour mode you could dedicate a bit to each, so every colour could be used straight, dimmed, inverted, or inverted and dimmed (the question of which effect to apply first is an open one of course).

      The machine actually has enough bandwidth as-is to support near-Amiga-32 colour mode output without any of the same CPU slowdown that mode causes to ChipRAM only machines, and 64 colours at a console-like 256 pixels horizontal with the same bandwidth (and thus full CPU speed). As well as 480 pixels with 8 colours, and 352~384 or 704~768 pixels with 16 or 4 colours.

      The concept is simple, really. What the shifter does is read a certain number of words into its internal buffer, at a steady, fixed rate, dumps them into the output register all at once, and then spits those bits out in a serialised/rearranged fashion under control of the pixel clock. In hi-rez mode, it reads just one word before flushing the buffer, and doesn't divide the master clock, so you get a single bitstream at 32MHz. Medrez, it reads 2, divides the clock by 2, and counts 2-bit pixels out at 16MHz. Low, it reads 4, divides by four, and produces 4-bit pixels at 8MHz. The beauty of the system is that it doesn't actually have to treat the data any differently in each mode - the input stage just steps up a row of the first buffer with each new word that comes in after a flush, then sends whatever's in that buffer to the second one when the flush signal happens, with any unfilled rows being left as all zeroes. So you only pick between entries 0 and 1 in hi-rez (and indeed the output just goes straight to the mono line through an inverter without even touching the palette), entries 0 to 3 in medium, and the full 0 to 15 in low. So altering that for a 3-bit mode is just a case of changing the clock and where the flush happens, and extending beyond 4 bits is a similar job plus adding the extra 16 bits of storage for each additional plane.

      Of course, 1280 divided by 3 is not 480, nor is 1280/6 actually 256. This is where the overscan comes in, and where the machine's higher clock rate vs the Amiga helps. The Miggy just about fits 320 pixels across a typical TV or default-settings monitor with a little underscan, at 7.1MHz (though a modern widescreen, or a suitably adjusted monitor, can show a few more). The ST showing the same image has noticable borders, because the pixels come out at 8MHz... which we can take advantage of. In the same space as the Amiga's 320, the ST gets about 360 (though you'd use 352 or 368 as those divide by 16). Or of course, at full mono clock rate, that becomes 1440. Which of course, divided by 3, becomes 480. Just about right for a minimal-acceptable-clarity 6x8 font with an 8-primary-colour palette (and maybe some subtle per-line/per-screen palette-switching cleverness, or just dithering, to better emulate the ANSI 16 for a terminal program), or indeed whatever you want to set.
      (break)

      Delete
  11. (2/3?)

    You can also divide by 5 to get 288 (your choice then of using that slightly oddball mode, or just 256 with a similar border to regular 320, or a full 320 with deep overscan equivalent to the ~400 pixels achieved with some demos on the real machine... or one of the valid inbetweens, ie 272 or 304 pixels), with 32 colours, or by 6 to get 240 in the same underscan space... or more usefully 256, which would go just into the overscan for a full-screen console effect. Especially if combined with a higher line count, say about 224 for NTSC or 264 for PAL, which would just be enough to produce a borderless display (as evidenced by machines like the MSX and Amiga which respectively use 212 for NTSC and 256 for PAL to fill the underscan with minimal borders). The actual pixel clocks of the NES, SNES and Master System, and the Megadrive in 256-pixel mode, are all about 5.73MHz (NTSC colourburst x8/5ths), after all; 32MHz/6 is 5.33, so the pixels would only be slightly fatter, a difference that probably wouldn't be noticed... and, hey, you're getting 64-colour pixels effectively for free, and with typical palette swapping effects (never mind any sprite trickery) that rises to easily 96 per line for static screens (possibly more if you're using halfbrite/invert type trickery and are very clever about colour usage, as you can effectively multiply the typical ~48 colours per line for Spectrum512/4096 mode to a full ~192, and in fact as more of the line is being used that number may be slightly higher, perhaps ~52 rising to ~208). And as a bonus, you can still technically produce 40-column text in that mode with the same 6x8 font... so it might be useful, at least with a full palette allowing a full gamut EGA-like 2-bit-per-channel setup, for stuff like full colour preview modes in DTP packages.

    And all that's within the regular 8MHz, 16 bit, 1:1 access contention, no buffering regieme, and single 32MHz master clock, with the only notable changes being within the Shifter (extra registers, more timing options), and a little inside the MMU (as I think it's responsible for the video clock division, as well as the timing of DE/Blanking plus syncs). As far as the pure job of reading video data from memory goes, nothing alters, other than the width (and height) of the active area and thus the size of memory being addressed. Changing how the bitplanes are addressed and interleaved within that space is a job for the programmer, as the rest of the system is doing nothing more than the same old task of linearly scanning through the buffer from start to end then looping back around.

    When you start increasing the bus speed (or width), messing with contention (and banking), and providing different master clocks, that's where things get interesting. And difficult to work out. It's not so bad with just straight 15kHz and 31kHz VGA (and indeed we could just use the TT crystal for the entire machine, as that's slightly faster than the original ST one in order to be directly divisible down to NTSC rate - which then makes VGA compatibility a cinch as it's based off NTSC and you can use a very simple clock divider to hit it dead-on), or even the better known alternative PC/Mac/etc standards (MDA/Hercules and EGA particularly are fine with 16MHz)...

    (break 2)

    ReplyDelete
  12. (3/3?)

    ...and naturally adding an NTSC crystal could be useful (especially with the help of a small line- or partial-frame-buffer to patch up the slight timing differences vs the rest of the machine) for the same reasons they're used in other machines intended for TV connection - you can hit the scan rates more or less perfectly, AND minimise dot-crawl effects where contrasting colours butt up against each other... and as the Amiga and Megadrive show, 7.1MHz (NTSC x2) is just right for neatly fitting 320 pixels across the screen. But it might also be handly to add a common PAL and/or VGA 25MHz crystal to fill in some of the gaps left by dividing those down, and add some better direct compatibility (in non-NTSC regions, and so you don't get the same huge borders exhibited by the TT when running on a generic, rather than Atari specific monitor without setting a trick 800+ pixel mode)... but their maths start to get a bit tricksy and it's a case of figuring out exactly what crystal, divider and line width combination is best to suit a certain monitor frequency.

    And thanks to that I've ended up in a whole weird side project trying to work out what the actual frequencies used by the various 1980s "25kHz" monitors and graphics cards, and just what the specs of certain common sub-/peri-VGA "enhanced EGA" modes (as well as some common extended Amiga modes) that were used on Multisyncs actually were so that the concept machine could have something similar specified for it and be fairly guaranteed of having decently wide compatibility, especially when running at an otherwise rather curious intermediate resolution... Actual mono mode, after all, is closer to SVGA / XGA Hsync rate than anything else, but its VSync is more like 400-line VGA, and overall scan structure is somewhere between the 400 and 480-line modes. It's a right oddball that modern screens don't always sync properly, and would have needed a multisync to use back in the day if you didn't have an Atari mono monitor. It would have been much easier for all concerned to e.g. add in a directly VGA-400 compatible mode... and maybe an SVGA one too. As well as built-in overscan to make better use of the actual available screen area on the mono monitors (the vertical blanking in particular is massive and makes me wonder why they didn't cut it down and run at 75Hz or more, as well as lengthening out the lines to reduce the Hsync a bit and then maybe produce a 720x400 mode for even better text quality; as-is, you can probably get 704x464 without too much drama...). Though you wouldn't really be able to do greyscale on it, not without some fancy extra-high-frequency PWM trickery as used by some PC cards to emulate more finely graduated greyscale on TTL "mono" (3- or 4-level), 16MHz monitors, as the input is literally 1-bit rather than analogue monochrome. A shame given that it's been recently demonstrated that the machine can produce 320x400 in 2bpp... in any case, your best option for a contemporary replacement would have been a colour or greyscale VGA, with the cheapest ones being fixed-frequency (and the very cheapest actually EGA or 25kHz, with a max of ~360 or ~420 active lines respectively) so you'd have needed modes that were compatible with that, which regular ST mono ISN'T...

    It'd have probably been easier to do this at the time, as the manufacturers could be contacted to get the actual pixel clock, horizontal and vertical sync frequencies / pixel-time and line counts, which are all you really need for a decent stab at it, or you could at least borrow a particular card/monitor and rent an oscilloscope and figure it out for yourself, but doing it in 2019 when the original documentation is thin on the ground, generally hopeless where it does exist, and hardly any of the same companies (and almost certainly none of the same staff) are still around 30+ years later is pretty challenging.
    (lolnope)

    ReplyDelete
  13. (4/3)
    I mean, if ANYONE knows what the actual layout of a typical 752x410/752x420 or non-VGA 640x480, sub-SVGA 800x560, 720x540, 720x512 mode actually was, in those terms, blast something to my google account, as I'd be morbidly fascinated to find out at long last. Every avenue so far has drawn a blank, other than some vague mention of 25kHz for 752x410 and 29.4kHz for 640x480 (which seems to be what the Amiga's doubled modes aim for as well). Or indeed many of the VGA-ish Amiga modes (and stuff like Euro36/Euro72/Super72), oddities like the Apple Lisa 608x432 "square pixel" board, Olivetti M10's 512x256 (and the M20's emulation of it, plus its native 640x400) for which only very vague specifications (e.g. "19MHz", which could be anywhere from 18.01 to 19.99 given experience with other documents) and quite a few entirely unreliable CRTC settings are available...

    ReplyDelete