The H5 roadmap

[exxos]

It still seems like a lot of people do not yet fully understand the H5 platform direction. So I will try and overview it.

Firstly, please see the other topics in the Phoenix zone relating to the E-boards, such as Trudie and Flashy-clock etc.

As people know, the original chipset is in short supply other than reusing chips from dead / broken machines. But this was a must to bring the H4/H5 platform to life and create a solid foundation to build upgrades upon. As people undoubtedly know, I have spent about 95% of my time chasing bugs in original hardware more than creating new hardware. Hence something had to change. The H4 & H5 was born. Now we can concentrate on upgrades and not have to mess about chasing faults for endless months.

The next step is to replace the original chipset with FPGA cores, which is the intention of the BLITTER PROJECT. Original blitters are hard to find, though they give us the first step in recreating the chips. Also we have had some success with the MMU PROJECT as well. And the HDMI SHIFTER project. The aim is to recreate the chips and also to add functionality.

This brings me back to the 16MHz bus project which was worked on and off for a while in other threads. The problem was the wakeup states make it difficult to create a stable acceleration. When the MMU wakeup states shift, you end up with a 1 in 4 chance of the machine booting up. Then a 50:50 chance of the video being shifted (wrap around issue). I made the call to abandon that project as it would take a lot of time to develop and not simple to fix. But also it's limited to 16MHz and there is "nothing next" which could be done. It would have resulted in a lot of work for essentially a dead-end project. The H5 platform is intended to do things properly and not do "nasty hacks" to get stuff done. It just wasn't a reliable method and would be end up being to difficult to implement for most people. So that project basically died out on all fronts.

This is again is why a FPGA chipset is important, as we can build it properly from the ground up and build in higher speed possibilities. The H5 platform already has a 32MHz-capable CPU and a SIMM which can easily be swapped out for different RAM. We may have to go to SRAM for higher speeds, but it's a simple swap to do with a dedicated RAM board. My SEC BOOSTER has pushed up to 75MHz, so there is already a new CPU ready to take on higher speeds if we can push past 32MHz. The current booster series aims to run ROM from fast-ram and have fast-ram which is capable of keeping up with the CPU.

Currently myself, @Icky, & @ijor are trying to build up development systems to prototype a FPGA based system, though it is not simple with the current parts shortages. Ultimately I hope such a FPGA board will replace the MMU, GLUE, BLITTER, and RAM with a 32MHz-capable system.

Work has already been experimented on HIGHER RESOLUTIONS There is already a driver which was hacked by @troed with the original chipset. So the possibility is already there to expand into better resolutions with a new FPGA based system and HDMI shifter.

Also mentioned for example in THIS THREAD, I want to add some STE functionality, like the DMA playback system, and expand upon it. A while back one of the demo coders who writes the tracker routines for most of the demo coders said he could write a playback engine to make use of such a system. I also want to add more features to reduce the CPU load in processing multiple tracker channels.

Overall, the aim is to have a fully backward-compatible ST machine with the option of switching into 32MHz modes, which, combined with a 32MHz blitter, would be, well, feking fast! Then we would have the bandwidth available to pipe higher resolutions to the shifter along with a quality tracker playback system. I think this for me would be my "Dream ST" as it's true to its ST roots and can make use of practically all existing ST software / games, plus have a true CPU bus acceleration which will eliminate the need for accelerators and other basically bodge-on hacks.

There are of course a lot of things going on in he background. As people know, I am patching TOS206 to function better with various hardware addons. So we also aim to have our own Phoenix OS which will control all the H5 addons from the desktop menu. So no need to have multiple AUTO programs and software to control the platform. We want it all to be as user friendly as possible! Nothing annoys me more than messing with multiple versions of software which tend to end up broken and an ongoing faff to get things done. I want that to simply END! I just want stuff to simply WORK!

I also hope the Phoenix platform will encourage new software developers to write demos and software for a brand new ST incarnation. We will have a lot of cool stuff for people to play around with. So I hope coders will take advantage and bring a new lease of life to the ST series!

So I hope this quick round-up makes it clear of the direction which the platform is heading in.

At the time of typing, the H5 Phoenix "barebones" motherboards are still available in the store. Worldwide shipping available.

https://www.exxosforum.co.uk/atari/store2/#0198

[Darklord]

Ambitious - but I like it! :)

[czietz]

I have to wonder, though: Why "hack" TOS 2.06, when there is EmuTOS? Imho, a modern, advanced hardware platform should be supported by a modern OS.

[Steve]

Very glad I have a H5 so I can come along on the ride, it looks like it'll be spectacular :D

[mrbombermillzy]

Thanks for the summary @exxos

So you are aiming for a 32Mhz system bus eh?

I'm very interested in seeing the speed gains that reducing bus contention has on specific types of STRAM code, as opposed to the more traditional strapping an 020/30/40/60 (maybe with Fast RAM) onto an 8mhz bus and boosting the wait states. :lol:

At some point, I guess I will have to coax someone into building a board for me so that I can dabble. :)

[exxos]

So you are aiming for a 32Mhz system bus eh?

Yes, but it will likely be done in steps. We know Simms can run at 16mhz. I'm not sure about 32mhz yet. It may need some waitstates on RAM. But RAM can be replaced anyway.

Main problem is probably going to be price vs performance on RAM.

32MHz is the likely limit of the motherboard bus and HC CPU.

While the SEC CPU can be clocked higher still, it will be more involved as the cpu needs "relocating" to the add-on board as no way its going to drive the 8mhz bus at higher than 32mhz CPU easily.

Its why I designed the SEC booster with full bus isolation so the cpu can access RAM fast without dragging the whole ST bus along with it.

But the SEC project is likely stalled indefinitely. Because it's still a hack and needing "fast RAM" to work. While it could be a add-on for the H4 /H5 its not going to be anywhere near as good as simply having a fast ST bus.

I'm very interested in seeing the speed gains that reducing bus contention has on specific types of STRAM code, as opposed to the more traditional strapping an 020/30/40/60 (maybe with Fast RAM) onto an 8mhz bus and boosting the wait states. :lol

Well if done correctly..
A old GB4 with benchmark..

32_result.jpg

That's a full 16mhz bus. 32mhz would double again.

Thing is, the blitter needs to be able to run at higher speeds also. If we have a proper 32mhz blitter with the full address bits, we will get a huge speed bump there without the usual 4mb ST RAM limits on DMA related stuff.

Once we have the faster bus, we can easily have more colours and higher resolutions etc without the need for graphics cards hacked on etc.

I'm planning this to all be add-on boards for the H4 /H5 series. Ultimately I may integrate all the mods into a new motherboard. But we are some years away with that yet. First step is to get a stable 16mhz system so people can start having some fun...

[mrbombermillzy]

At some point, I guess I will have to coax someone into building a board for me so that I can dabble. :)

Stage complete! 8-)

Thing is, the blitter needs to be able to run at higher speeds also. If we have a proper 32mhz blitter with the full address bits, we will get a huge speed bump there without the usual 4mb ST RAM limits on DMA related stuff.

To avoid blitter bandwidth saturation to some degree, one (IMHO) essential thing I will beg yourself/Icky/Igor to be added to the blitter is a 'Copy if ! = ' logical operator for either palette index numbers (8bpp) and/or RGB value (for chunky modes). Paired with a 8bpp indexed graphics mode, this will shave 33% off of general game related (i.e. background with foreground non square sprites/bobs) blit operations. And it shouldnt be much of a problem to implement. (Famous last words :lol: )

I have spoken about my blitter wish list on the above linked 'blitter recreation thoughts' thread:

viewtopic.php?p=125086#p125086

I'm planning this to all be add-on boards for the H4 /H5 series. Ultimately I may integrate all the mods into a new motherboard. But we are some years away with that yet. First step is to get a stable 16mhz system so people can start having some fun...

Of course. All of our projects take time. I look forwards to see how each small step progresses, whilst taking the liberty of planting design 'seeds' early along the path, in case they get noticed! :)

However, I digress with too much blitter talk...having the system bus in parity with the CPU speed will be very interesting to see when it happens.

Please continue the great work! :cheers:

[exxos]

To avoid blitter bandwidth saturation to some degree, one (IMHO) essential thing I will beg yourself/Icky/Igor to be added to the blitter is a 'Copy if ! = ' logical operator for either palette index numbers (8bpp) and/or RGB value (for chunky modes).

I was chatting to @ijor some months ago about speeding up the blitter. I think it was giving the blitter direct access to RAM without having to do bus cycles.. but really can't remember now :(

I think mostly my thoughts were trying to reduce the amount of time the blitter "hogs" the bus for, because it takes time away from the CPU for starters. If we have the bandwidth to RAM, the blitter doesn't have to be "locked" into 8MHz or 32mhz even. Its all internal in the FPGA, so it can go as fast as RAM will allow. I'm just pulling numbers out of my a$$, but think like 100MHz blitter even if the CPU can only manage 16MHz kind of thing.

But you would have to convince @ijor about adding new functions into the blitter. I think @Cyprian was also asking similar a while ago.

I originally was thinking similar, because if things like the blitter can do screen clears faster, GEM would get a speed boost that way alone. NVDI will still likely be faster I assume though. But a faster blitter opens the door for all sorts of new possibilities, in games etc..

[mrbombermillzy]

I think mostly my thoughts were trying to reduce the amount of time the blitter "hogs" the bus for, because it takes time away from the CPU for starters. If we have the bandwidth to RAM, the blitter doesn't have to be "locked" into 8MHz or 32mhz even. Its all internal in the FPGA, so it can go as fast as RAM will allow. I'm just pulling numbers out of my a$$, but think like 100MHz blitter even if the CPU can only manage 16MHz kind of thing.

Yeah, high blit bandwidth like the above would certainly work wonders from a game oriented perspective as well as OS (GEM/(N)VDI,etc).

But you would have to convince @ijor about adding new functions into the blitter. I think @Cyprian was also asking similar a while ago.

I originally was thinking similar, because if things like the blitter can do screen clears faster, GEM would get a speed boost that way alone. NVDI will still likely be faster I assume though. But a faster blitter opens the door for all sorts of new possibilities, in games etc..

If the speed can be cranked right up anywhere close to the figures quoted in the first paragraph, thats wonderful! :)

However, Im looking at how to achieve the best results for the least effort from your end...I dont want you guys having to spend more time on extra features. But if you can eliminate a third of any game oriented blit operation by adding a small logic function, I think that should perhaps be looked into.

Unfortunately, the GEM desktop may not benefit, as I dont think the (proposed removal of the) extra mask blit is needed for the GEM VDI blitter operations.

[exxos]

. But if you can eliminate a third of any game oriented blit operation by adding a small logic function, I think that should perhaps be looked into.

Unfortunately, the GEM desktop may not benefit, as I dont think the (proposed removal of the) extra mask blit is needed for the GEM VDI blitter operations.

I don't know much about Blitter coding.. I did read your other blitter post, but still no wiser :lol: of course I'm always open to improving things if it's simple and not likely to break anything..

There could be a whole bunch of extra logic functions which could be added to make life easier for coders..