how far can the graphics go.

[kegnkiwi]

I would just say my N-go is fantastic and playing the old games is great, but I would like to know do you think the next/n-go is restricted and can do more in the future. I ask because on some models there is a pi zero accelerated. I listen and there are threads about unlocking more cores etc. This board is like 4 x the price of a pi 4 and is massive compared to it. Do you think the next could ever play games like the emulators you can get for the pi 4? Playing mega drive games or ps1? I know it was designed the way it is but I'm just interested if it can do more.

[kegnkiwi]

I think i can answer maybe my own question. A google search seems to show graphics around the gameboy advance level can be reached.

[spider]

Pointless comment sorry but when I saw the topic title and before I read it, I'd somehow assumed by "how far" the topic was going to be about extending them into the border with some careful timing.

[Alcoholics Anonymous]

The Spectrum Next itself has limitations that are imposed by the fpga capacity and a decision to root the design in a "what could have been possible in the 1990ish time frame idea" by logically extending the spectrum architecture. Most of the fpga is actually taken up with circuitry for backwards compatibility concerns, implementations of common hardware add-ons, and fully taking advantage of the z80 architecture which the original machine didn't do.

But the limitations of the pcb itself are determined by the peripherals on the board and the capacity / speed of the fpga. The board itself supplies ps/2, vga, hdmi, gpio to optional pi, 2MB sram, joystick connectors, serial interfaces (one to wifi module), sd card, rtc, etc. The fpga is a blank slate for whatever circuit you want to design. The output resolution to vga/hdmi is capped by how fast the fpga can drive signals. The Next is driving 576p (720x576) and 480p (720x480) resolutions on hdmi. All the hardware to drive this stuff is implemented in the fpga so you can change these characteristics.

For the Spartan 6 I don't think hdmi resolutions much above 576p and 480p can be a thing due to fpga speed but I haven't determined what the limit actually is. Keep in mind you need to fetch display data either from external memory or internal memory on the fpga to generate the display so there are separate limitations there. The higher the resolution, the more memory you need and the higher the memory bandwidth has to be to support it.

On the Spartan 6 LX16, there is space to do all 8-bit machines, some 16-bit machines, some arcade machines.

The pi zero is another thing. The Spectrum Next is constructed as a multi-computer system as in there are two different and independent computers (one z80 and one arm) on one pcb that can be either lightly or tightly coupled through the pi's gpio connector.

How the two computers are connected is completely up to the fpga design and can even change from core to core. For example, the bbc community uses the pi as a fast 6502 through the bbc tube. A bbc core running on the spectrum next could use the pi in exactly the same way. The Spectrum Next has a less coupled interface (for now at least) that treats the pi as a linux box that offers services like audio player (sid, mp3, sndh, etc) and tzx player. SInce the pi has its own hdmi out, you can also use the pi as a pi with the Next sending commands to its shell as if they were typed in at a pi keyboard. As far as trading graphics back and forth, you could get the Next to tell the pi what to draw on its own display or vice versa. Resolutions on the pi end would be whatever the pi supports and resolutions at the Next end would be whatever the Next supports. Other ideas are using the pi as a ram store (for cores that require more ram), having the pi emulate hardware add ons, giving a display surface to the pi within the Next and so on.

[kegnkiwi]

Thank you for a great reply.

Post edited by PJ

[funkheld]

Hi good afternoon.
at 73 i like to play with the vforth for the next/n-go.
there is an example how to connect to the Raspberry PI Zero and the vforth.

i like this vforth because it can use the next/n-go into the system with simple self-made forth words.

I can't find any other programming language that is fast and works well on it (this Nextbasic is very slow). if you want to do a little more then the only option left is nexzbuild or asm.

greeting

the first step of Mmattsteel

Code: Select all

( UART Raspberry PI Zero raw-terminal )
\
\ This TERM0.F provides a simple terminal to talk with Raspberry PI Zero
\ via UART.
\

NEEDS LAYERS
NEEDS MS     
NEEDS TRUV    
NEEDS INVV

\
MARKER DONE  \ Useful to rollback dictionary memory to this point
\

HEX 
5C08 CONSTANT LASTK          \ system variable
143B CONSTANT UART-RX-PORT
133B CONSTANT UART-TX-PORT
153B CONSTANT UART-CT-PORT


\ Table of actual clock speeds depending on video mode
\ These are double precision integers you can read with 2@
\ See Manual: NextReg 17 (11h) - Video Timing
HERE
DECIMAL \ values are divided by 100 to better handle them
  28.0000   , ,   \ Base VGA timing   28 MHz
  28.5714   , ,   \ VGA setting 1     28.571.429 Hz
  29.4643   , ,   \ VGA setting 2     29.464.286 Hz
  30.0000   , ,   \ VGA setting 3     30 MHz
  31.0000   , ,   \ VGA setting 4     31 MHz
  32.0000   , ,   \ VGA setting 5     32 MHz
  33.0000   , ,   \ VGA setting 6     33 MHz
  27.0000   , ,   \ Digital           27 MHz
CONSTANT SYS-CLK-ARY


HEX
\ compute actual clock speed depending on video mode
: SYS-CLOCK ( -- d )
  11 REG@ 7 AND          \ Video timing register: 0-7
  4 * SYS-CLK-ARY + 2@   \ fetch from array created before
;

\ send 14-bits prescalar to UART receive port
\ prescalar = sysclock / baudrate
: UART-SET-PRESCALAR ( n -- )
  DUP
  7F AND UART-RX-PORT P!      \ send low 7 bits of 14 bits
  7 RSHIFT                    \ presclar
  80  OR UART-RX-PORT P!      \ send high 7 bits of 14 bits
;


DECIMAL
\ compute prescalar to be used with previous definition
: UART-BAUD-TO-PRESCALAR ( d -- n )
  100 M/          \ divide BAUD by 100 to able to handle it
  SYS-CLOCK       \ obtain actual system clock speed / 100
  ROT M/
;

\ usage is: 115200. UART-SET-BAUDRATE
: UART-SET-BAUDRATE ( d -- )
  UART-BAUD-TO-PRESCALAR
  UART-SET-PRESCALAR
;


HEX
\ Select Raspberry PI Zero UART and set Baudrate
\
: PI0-SELECT  ( d -- )
  40 UART-CT-PORT P!    \ select PI Zero UART control port
  UART-SET-BAUDRATE     \ uses double integer param
  30 A0 REG!            \ PI Pheripeal enable
\ 91 A2 REG!            \ PI I2S Audio control
;


HEX
\ non-zero when transmitter is busy sending a byte
: ?UART-BUSY-TX ( -- f )
  UART-TX-PORT P@   \ UART TX port
  02 AND            \ bit is set when busy
;

\ There is no transmit buffer so program must make sure the
\ last transmission is complete before sending another byte
: UART-TX ( b -- )
  BEGIN
    ?UART-BUSY-TX  0=  ?TERMINAL OR
  UNTIL
  UART-TX-PORT P!         \ Transmit
;

\ Utilities
DECIMAL
\
: UART-SEND-EOT ( -- )   \ End Of Transmission
  04 UART-TX
;
\
: UART-SEND-ETX ( -- )   \ End of TeXt
  03 UART-TX
;

HEX
: ?UART-BYTE-READY  ( -- f )  \ non zero when byte ready
  UART-TX-PORT  P@ 
  01 AND
;

: UART-RX  ( -- b | 0 )       \ accept a byte
  UART-RX-PORT  P@
;

: UART-WAIT ( b -- )     \ wait for a specific byte or Break
  BEGIN                       \ b
    UART-RX OVER =            \ b f
    ?TERMINAL OR              \ b f
  UNTIL DROP                  \
;

\ wait for a byte with timeout in ms
: UART-RX-TIMEOUT ( n -- c | 0 )
  0 SWAP                      \ 0 n
  1+ 0                        \ 0 n+1 0
  DO                          \ 0
    ?UART-BYTE-READY IF       \ 0
      UART-RX                 \ 0 b
      SWAP DROP               \   b
      LEAVE                   \   b
    THEN                     \ 0
    1 ms                      \      minimum delay
  LOOP                        \ 0
;

HEX
\ simple wait for a specific string "SUP> "
: UART-WAIT-PROMPT  ( -- )
  [CHAR] S UART-WAIT
  [CHAR] U UART-WAIT
  [CHAR] P UART-WAIT
  [CHAR] > UART-WAIT
        BL UART-WAIT
;

HEX   \ map special Symbol-Shift Keys
HERE  \ stop not step to then and or
E2 C, C3 C, CD C, CC C, CB C, C5 C, C5 C, 0C C,
 CONSTANT TKB1

HERE  \  ~    |   \   {  }    [   ]
7E C, 7C C, 5C C, 7B C, 7D C, 5B C, 5D C, 08 C,
 CONSTANT TKB2

\
\ map above listed char-code.
\ should handle Caps-Lock key too.
: MAP-KEYB ( c -- c )
  >R TKB2 TKB1 8 R> (MAP)
  DUP 6 = IF 8 5C6A TOGGLE THEN  \ handle caps-lock
;

HEX
\ Terminal basic initialization 
: TERM0-INIT   ( -- )
  0 LASTK C! 0 5C6A C! 0D UART-TX
  6 1E EMITC EMITC  \ narrow font 85 char per row.
  LAYER12
  HEX
;

: TERM0-DONE
  8 1E EMITC EMITC  \ normal font 64 char per font
  DECIMAL
;

: TERM0
  TERM0-INIT
  BEGIN
    LASTK C@ ?DUP IF
      MAP-KEYB  DUP UART-TX  0 LASTK C!
    THEN
    ?UART-BYTE-READY IF UART-RX
      DUP 80 < 0= IF INVV THEN 7F AND  \ force ascii 7-bits
      DUP 20 < IF INVV DUP . THEN      \ non-printable
      DUP 0D - IF EMIT THEN TRUV       \ ignore CR
    THEN
  ?TERMINAL UNTIL TERM0-DONE
;

( UART Raspberry PI Zero - testing )

  DECIMAL 115.200 PI0-SELECT
  UART-SEND-ETX
  UART-SEND-EOT
  UART-WAIT-PROMPT

  TERM0

[Alcoholics Anonymous]

I can't find any other programming language that is fast and works well on it (this Nextbasic is very slow). if you want to do a little more then the only option left is nexzbuild or asm.

You can also program in c using z88dk. Many of the dot commands and some software like nextdaw, magnetic scrolls adventures and the level 9 adventures are written in c.

[funkheld]

------------------------------
You can also program in c using z88dk
------------------------------

Hi, Thank You.
This z88dk is still in its infancy for the Next and totally unwieldy for beginners.
it is only used by very few professionals for the next.

I think it's not in our league...
I also don't find any reasonable instruction for the next for the z88dk, which is intended for entry.


greeting

[Lethargeek]

The Spectrum Next itself has limitations that are imposed by the fpga capacity

nope, as the notorious TS-conf was made for much, much older and weaker FPGA and is more powerful as gaming platform in most respects

and a decision to root the design in a "what could have been possible in the 1990ish time frame idea" by logically extending the spectrum architecture. Most of the fpga is actually taken up with circuitry for backwards compatibility concerns, implementations of common hardware add-ons,

hardware tile/sprite engine definitely is NOT a logical extension of the spectrum architecture
more like logical consequence of authors' mindset and background

with a real logical extension there won't be ever any need for things like pi zero "accelerator"

and fully taking advantage of the z80 architecture which the original machine didn't do.

dunno what's this even supposed to mean
especially when they messed with z80 architecture itself

[Alcoholics Anonymous]

nope, as the notorious TS-conf was made for much, much older and weaker FPGA and is more powerful as gaming platform in most respects

Definitely not.

For the main question, you need to stop thinking like an emulator author and understand how hardware works. The maximum resolution display by the Spectrum Next PCB is set by the signal bandwidth of the fpga. The fpga is responsible for generating the hdmi signal; the hardware designer creates the logic to create a compliant hdmi signal. hdmi is a conglomeration of standards with the low end around 720x480 @ 60Hz and 720x576 @ 50Hz. The high end is 4K video. As you select higher resolution, the signalling speeds up and requires higher bandwidth i/o. The max bandwidth is limited by the particular fpga and is tied to the technology node the fpga is created on. The Spartan 6, which the original Nexts are using, is on the 45nm node but Xilinx also included high speed drivers on its i/o for this particular fpga so it performs better than other manufacturer's fpgas on the same node. The Spectrum Next only generates the mentioned 480p and 576p resolutions with artificially limited colour range because the Spectrum is a very low resolution device. This is not the limit of what the fpga can produce and another hardware design configured into the fpga is free to generate higher resolutions. I do not know what the top resolution the Spartan 6 can deliver is but I don't believe it's much higher than 480p / 576p. Maybe 720p is possible (but that's a fairly big step) and maybe interlaced can make that possible.

You seem to be confused about what the implications of a "weaker fpga" are. The Spectrum is a very simple machine and most of its logic was implemented on the "weakest fpga" known as the ULA. Any logic device made after the ULA can easily fit Spectrum video into it. Even if you used the latest and greatest logic device from today, it wouldn't make a difference because the ULA implementation will behave the same on whatever logic device it can be implemented on.

The same goes with these enhanced video modes. They are not pushing anyone's fpga and it doesn't help if you have a bigger one. The Spectrum Next's video is the way it is because it is an extension of the original's video. In fact, its pixel rate is identical to the 1983 TS2068 at 14 MHz. The low resolution hdmi above operates at 27 MHz (270 MHz serial pixel clock <--- this is the bandwidth problem) and in between there has to be hardware to map from one signal to the other since the Spectrum's video is incompatible with modern standards.

I think you also overestimate how much logic is required to implement these video enhancements. In the Spectrum Next, I'd guess that roughly 15% of the fpga's logic gates are taken by the new video features. The rest is in things like software & hardware compatibility with several Spectrum models, making full use of the Z80 architecture, integrating many common Spectrum & Z80 peripherals, and interfacing with modern peripherals around the pcb like hdmi. A comparatively "weaker" fpga is going to be missing things in the last 85%.

About TS-config specifically, it relies on the characteristics of sdram which was invented in the mid 1990s. sdram supplies the necessary memory bandwidth that TS-config is using and actually determines what sort of video features are possible. With sdram providing much of the memory logic, the Z80 located outside the fpga and other functions implemented around the pcb, that frees a lot of gates for other things even on a "weaker" fpga.

hardware tile/sprite engine definitely is NOT a logical extension of the spectrum architecture
more like logical consequence of authors' mindset and background

The reason why 8-bit cpus saw variations of the same hardware accelerators repeated in hundreds to thousands of different machines is because they were the most cost effective and performative way to enhance displays as resolutions increased for 8-bit cpus.

Let's have a look at what some of the competition was like for a 1990 Spectrum:

CPC6128+ (1990)
Palette of 4096 colours, 320x200 16 colours per pixel, 640x200 2 colours per pixel, hardware sprites, hardware assisted scrolling

MSX2+ (~1988)
80x24 character text mode, 256x212 with 19268 colours to 512x212 with 16 colours per pixel from 512, hardware sprites, hardware scrolling

C65 (~1992 if it came out)
80x25 character text mode, 256 colour palette from 4096 colours, 320x200 256 colours per pixel to 1280x400 4 colours per pixel, hardware sprites, hardware scrolling

Lots of colours, tilemaps, hardware scrolling, hardware sprites, high resolutions with per pixel colour. I only mentioned these three but the same is true of (nearly?) all 8-bit systems starting in the 1970s (home computer, business computer, scientific computer, embedded system, home video game system, arcade) -- they all used variations of the above in order to deal with high resolution displays.

I know some know this part already but many others don't so I'll state it anyway.

The Spectrum and all the other 8-bits of that era had the characteristics they did because of budgetary and technological constraints of ~1982. The designers did not wake up every morning and try to figure out the best way to cripple their machines. Rather, they tried to do the best they could within the constraints they had. Colour clash was a compromise between the desire to have high resolution graphics and the limited memory space available.

In 1990, the Spectrum's designers, again, would not have been dreaming about how best to cripple the Spectrum, but rather they would have been trying to make the best machine they could. The CPC, MSX and C64 lines did try to do that and their characteristics are listed above. Notice that I've omitted the Spectrum line. This is because no one was trying to improve the line. Sinclair had no plan to make follow up machines (the 128K came from Spain) and Amstrad saw it as a budget machine underneath the CPC so it only made minor improvements to keep the line selling.

The quintessential characteristic of the Spectrum was a fast cpu coupled with a bitmap. It was blind luck that the ratio the Spectrum got, 3.5 MHz : 6912 bytes, was good enough to make games comparable with its contemporaries. Had it not, it would have died, as many other machines did.

In 1990, there's no question the Spectrum would have gotten a full colour bitmap. 256x192 with 256 colours per pixel is the same pixel resolution as the original, is easy to implement in hardware (easier than the ula), is easy to use in software and is competitive with its 1990 contemporaries. It's a reasonable choice.

Every 8-bit machine faced the same problem as display resolutions increased and that was that 8-bit cpus did not keep pace in speed. Even if we assume the Spectrum would have aimed to keep the top cpu speed in class, that would have been the 10 MHz Z80 in 1990, leading to a ratio of 10 MHz : 49152 bytes for its full colour display. That's more than twice as slow as the original display. Had it stayed at 3.5 MHz, it would have been almost eight times slower.

The primary function of the Spectrum was to play games. With a higher resolution display, you end up with something slower than the original and much slower than the competition. Fortunately 1990 also meant a whole bunch more gates were available to do new things and the best way to spend those would have been on the display hardware.

The Spectrum Next's tilemap is coming by way of the +3. Amstrad added cp/m capability but didn't increase the screen resolution. So the +3's cp/m programs ran on the same 256x192 screen and they tried to make due with a squashed 64x24 text display. That's simply not usable for any serious cp/m machine. Although cp/m terminals are allowed to be any text resolution, in reality cp/m software standardized on 80x24 in the 1970s and anything less just doesn't work very well in most cases. So this attempt was taken seriously and the use of Spectrums as home productivity tools was also taken seriously so we made sure the tilemap would have at least an 80x24 text resolution so that these applications could be done well. The fact that tilemaps are also good for games made it doubly attractive and the fact that the tilemap hardware is relatively simple (maybe 3-4x the ula?) makes it a good choice to spend gates on.

Hardware scrolling is so simple to do, it's almost embarrassing. A very good candidate to include.

With ula, high colour resolution display, tilemap and hardware scrolling I think you could go quite far in terms of games and these things are a reasonably unchallenging gate count for 1990. If you want to be at the top of the budget computer heap, hardware sprites ensure that. The Spectrum Next's implementation is probably at similar complexity as the 1979 TMS9918 circuit (but with all gates devoted to sprites) and shares the idea that the circuit owns its own ram with cpu access via i/o ports.

Sprites actually went in right at the beginning as a feature of the "pi graphics accelerator" (hence the name) when the pi was going to be responsible for generating hdmi video. It was there to help make programming fun for basic programmers. The situation changed when the stretch goal for bigger fpga was reached which moved everything into the fpga as real hardware and left the pi as an optional peripheral.

hardware tile/sprite engine definitely is NOT a logical extension of the spectrum architecture
more like logical consequence of authors' mindset and background

I actually know what you mean here because you have your own project to colour spectrum games.

My point is tilemaps, sprites, hardware scrolling were used to handle increased resolutions in 8-bit displays by hundreds of different systems because they give the best performance for the buck. It's not because it's "mindset".

With your solution, the goal is to produce something that is mainly for colouring existing Spectrum games. The computer produced might be fine for that but it would lag seriously behind what other machines using tilemaps / sprites / hardware scrolling could do. Programmers would prefer these methods for making new games as well.

You decide what you are making. A competitive machine or an incremental improvement? The Spectrum Next chooses the former.

with a real logical extension there won't be ever any need for things like pi zero "accelerator"

You don't need it. It's an optional peripheral.

and fully taking advantage of the z80 architecture which the original machine didn't do.

dunno what's this even supposed to mean
especially when they messed with z80 architecture itself

One of the main distinguishing features of the Z80 is its vectored interrupt capability. The ULA not being an im2 peripheral (and subsequent assumptions made by spectrum add-on manufacturers) meant properly taking advantage of that was not possible. The Z80 family's peripherals are also best used in im2 mode (the Next implements the dma and the ctc; the original Spectrum had a few peripherals that used the pio and sio). As a Z80 machine, the Spectrum was a little handicapped by these things in comparison to more expensive Z80 machines used in academic and scientific circles especially.

In the Next, there is a hardware im2 mode which prioritizes up to 14 maskable interrupt sources, including optional ability to interrupt dma transfers, and both programs and some peripherals can generate nmi interrupts. Coupled with a few things like enhanced divmmc interface and flexible memory paging, this makes the Next a powerful Z80 machine that tries to take advantage of everything the Z80 architecture offers.

[catmeows]

I quite disagree.
1)we have seen evolution of Spectrum: first there was 128K model, then Sam Coupe, then russian models.
2) honestly, I don't understand whole idea of Spectrum 1990. Even most viable 8 bit models were dying by 1991/92.
3) You name Amstrad CPC128+, MSX+, C65 as examples of development of 8 bit models that focused on massive hardware accelaration. I could name Tandy Coco 3 and Apple II GS as example of going the other side: boosted cpu power to keep pace with bigger video buffer.
4) I would like to point out that for lowcost gaming in 90s high resolution did not make sense. Most succesfull platforms in this niche were consoles connected to CRT TV and up to PS1 they used pretty low resolutions.
5) I also think that you failed to identity the real bottleneck. It was memory bandwith, not cpu power.
6) So, I think your presentation of Next design as the only viable way is misleading. It was really about mindset.

[Lethargeek]

nope, as the notorious TS-conf was made for much, much older and weaker FPGA and is more powerful as gaming platform in most respects

Definitely not.

Definitely yes, as the TS-conf has 2+3 tile+sprite layers vs Next having 1+1 (both have one bitmap layer as well). Moreover, the major design flaw of the Next is keeping the active sprite pixels in the internal FPGA pattern memory. Just 16K of 8/4-bit pixels is really NOT MUCH. It's just 128x128/256x128 rectangle, less than the Spectrum screen. And speaking of Spectrum, we have examples like Nemesis the Warlock (a 48k game!) with its 22K of masked sprites - that's whopping 88K of non-masked sprite pixels, almost 3 times (!) more than fits into the Next's pattern memory! And because the nature of the game, ANY of these might be needed for any given frame, not to say level, and hardware mirroring and rotating won't help as well. OTOH no problem for the TS-conf as it reads its sprite pixels from memory.

For the main question, you need to stop thinking like an emulator author and understand how hardware works.

First you need to stop thinking that you know how i'm thinking. Because i'm thinking like a hardware concept author. The emulator was born out of this knowledge. It seems you're under false impression that i'm disagreeing with you because i know little when the exact opposite is true - i'm disagreeing because i know too much, too well. So please be so kind and stop lecturing me on the basics i likely understand better than you. Let's try talking more numbers, less opinions.

The same goes with these enhanced video modes. They are not pushing anyone's fpga and it doesn't help if you have a bigger one.

ahaha, as we've seen it would certainly have helped if Next had more internal pattern memory for the sprite pixels

I think you also overestimate how much logic is required to implement these video enhancements. In the Spectrum Next, I'd guess that roughly 15% of the fpga's logic gates are taken by the new video features. The rest is in things like software & hardware compatibility with several Spectrum models, making full use of the Z80 architecture, integrating many common Spectrum & Z80 peripherals, and interfacing with modern peripherals around the pcb like hdmi. A comparatively "weaker" fpga is going to be missing things in the last 85%.

And i think you're overestimating the cost of everything else. Also, even 15% of the new Xilinx may still be more than 100% of the ancient Altera.

The reason why 8-bit cpus saw variations of the same hardware accelerators repeated in hundreds to thousands of different machines is because they were the most cost effective and performative way to enhance displays as resolutions increased for 8-bit cpus.

NO. CPU bitness had nothing to do with it. Memory cost and performance was the real reason. NOT A PROBLEM NOW (for quite a time already).

About TS-config specifically, it relies on the characteristics of sdram which was invented in the mid 1990s. sdram supplies the necessary memory bandwidth that TS-config is using and actually determines what sort of video features are possible. With sdram providing much of the memory logic, the Z80 located outside the fpga and other functions implemented around the pcb, that frees a lot of gates for other things even on a "weaker" fpga.

You say SDRAM as it is an advantage. It is not as the random access is not that great. Plus this particular one is old as well, and it works at mere 7MHz.

Let's have a look at what some of the competition was like for a 1990 Spectrum:

CPC6128+ (1990)
Palette of 4096 colours, 320x200 16 colours per pixel, 640x200 2 colours per pixel, hardware sprites, hardware assisted scrolling

MSX2+ (~1988)
80x24 character text mode, 256x212 with 19268 colours to 512x212 with 16 colours per pixel from 512, hardware sprites, hardware scrolling

C65 (~1992 if it came out)
80x25 character text mode, 256 colour palette from 4096 colours, 320x200 256 colours per pixel to 1280x400 4 colours per pixel, hardware sprites, hardware scrolling

Lots of colours, tilemaps, hardware scrolling, hardware sprites, high resolutions with per pixel colour. I only mentioned these three but the same is true of (nearly?) all 8-bit systems starting in the 1970s (home computer, business computer, scientific computer, embedded system, home video game system, arcade) -- they all used variations of the above in order to deal with high resolution displays.

Yeah - SOME, as already mentioned by @catmeows . But not all. BTW i think the Next would be better machine if it was designed as an enhanced MSX with added Spectrum compatibility rather than a Spectrum with MSX-like (but not MSX-compatible) extra features. But then it couldn't be hyped as the next Spectrum of course.

The Spectrum and all the other 8-bits of that era had the characteristics they did because of budgetary and technological constraints of ~1982. The designers did not wake up every morning and try to figure out the best way to cripple their machines.

managers did

Rather, they tried to do the best they could within the constraints they had. Colour clash was a compromise between the desire to have high resolution graphics and the limited memory space available.

and the memory speed and space IS NOT A PROBLEM ANYMORE, for a long time!
how many times i need to repeat this for you to grasp such a simple fact?

The quintessential characteristic of the Spectrum was a fast cpu coupled with a bitmap. It was blind luck that the ratio the Spectrum got, 3.5 MHz : 6912 bytes, was good enough to make games comparable with its contemporaries. Had it not, it would have died, as many other machines did.

In 1990, there's no question the Spectrum would have gotten a full colour bitmap. 256x192 with 256 colours per pixel is the same pixel resolution as the original, is easy to implement in hardware (easier than the ula), is easy to use in software and is competitive with its 1990 contemporaries. It's a reasonable choice.

hence, the "LOGICAL extension of Spectrum architecture" would be a better bitmap, as i already said

Every 8-bit machine faced the same problem as display resolutions increased and that was that 8-bit cpus did not keep pace in speed. Even if we assume the Spectrum would have aimed to keep the top cpu speed in class, that would have been the 10 MHz Z80 in 1990, leading to a ratio of 10 MHz : 49152 bytes for its full colour display. That's more than twice as slow as the original display. Had it stayed at 3.5 MHz, it would have been almost eight times slower.

With just a CPU to work the bitmap yes. With LITTLE hardware help (something akin to EGA) it would have been a bit faster actually. With MORE hardware help (even a simple blitter) - a LOT faster.

The primary function of the Spectrum was to play games. With a higher resolution display, you end up with something slower than the original and much slower than the competition. Fortunately 1990 also meant a whole bunch more gates were available to do new things and the best way to spend those would have been on the display hardware.

But why spend it on more complicated hardware that's good ONLY for playing games when there are other solutions?

Hardware scrolling is so simple to do, it's almost embarrassing. A very good candidate to include.

hardware scrolling is an obsolete kludge from the era of costly and slow memory
with a simple blitter you don't need a dedicated (limited) scrolling, you get it as a bonus and pixel-precise

With ula, high colour resolution display, tilemap and hardware scrolling I think you could go quite far in terms of games and these things are a reasonably unchallenging gate count for 1990. If you want to be at the top of the budget computer heap, hardware sprites ensure that. The Spectrum Next's implementation is probably at similar complexity as the 1979 TMS9918 circuit (but with all gates devoted to sprites) and shares the idea that the circuit owns its own ram with cpu access via i/o ports.

You can't be serious. TMS9918 is nowhere near quantitatively. Also i think even 9918 is more complex than several EGA-like latch registers.

I actually know what you mean here because you have your own project to colour spectrum games.

it is only part of the project

My point is tilemaps, sprites, hardware scrolling were used to handle increased resolutions in 8-bit displays by hundreds of different systems because they give the best performance for the buck. It's not because it's "mindset".

And my point is that hardware tile/sprite engines were a solution to a problem that doesn't exist anymore (see above). So NOW it IS a "mindset"

With your solution, the goal is to produce something that is mainly for colouring existing Spectrum games. The computer produced might be fine for that but it would lag seriously behind what other machines using tilemaps / sprites / hardware scrolling could do.

No, the goal was a powerful but flexible extension, with gradual existing software improvements possible with the ability to stop and enjoy the result at any moment. But nothing forces the result to "lag behind what other machines" except programmer's decisions.

Programmers would prefer these methods for making new games as well.

programmers would prefer more powerful, flexible and easier to use features
blitter is all of these things for 2D once the memory size and bandwidth is enough

with a real logical extension there won't be ever any need for things like pi zero "accelerator"

You don't need it. It's an optional peripheral.

optional for what?

One of the main distinguishing features of the Z80 is its vectored interrupt capability. The ULA not being an im2 peripheral (and subsequent assumptions made by spectrum add-on manufacturers) meant properly taking advantage of that was not possible. The Z80 family's peripherals are also best used in im2 mode (the Next implements the dma and the ctc; the original Spectrum had a few peripherals that used the pio and sio). As a Z80 machine, the Spectrum was a little handicapped by these things in comparison to more expensive Z80 machines used in academic and scientific circles especially.

In the Next, there is a hardware im2 mode which prioritizes up to 14 maskable interrupt sources, including optional ability to interrupt dma transfers, and both programs and some peripherals can generate nmi interrupts. Coupled with a few things like enhanced divmmc interface and flexible memory paging, this makes the Next a powerful Z80 machine that tries to take advantage of everything the Z80 architecture offers.

well, this is definitely not "everything" from programmer's POV

[AndyC]

Let's have a look at what some of the competition was like for a 1990 Spectrum:

CPC6128+ (1990)
Palette of 4096 colours, 320x200 16 colours per pixel, 640x200 2 colours per pixel, hardware sprites, hardware assisted scrolling

It's actually 160x200 16 colours, 320x200 4 colours or 640x200 2 colours. The same resolution as the original CPC, just with a wider range of colours.

I'd agree with the main sentiment though. 8 and 16 bit machines typically relied on hardware assistance of common functionality to make up for CPU limitations and I'd imagine a souped up Spectrum would've gone in a similar manner, even if it perhaps doesn't follow the original philosophy behind the design.

Indeed the one contemporary you missed off, the Sam Coupé, didn't add things like hardware scrolling and sprites and it very much suffers in performance as a result.

[catmeows]

Indeed the one contemporary you missed off, the Sam Coupé, didn't add things like hardware scrolling and sprites and it very much suffers in performance as a result.

IMHO, Sam Coupe problem can be tracked down to usage of pair 256kbx4 DRAM chips. Sam use fast 100ns DRAM but they seem not fast enough to be accessed by both video and CPU. Honestly, I don't know what exactly is wrong with Sam timing, Amstrad was able to make 4Mhz Z80 run on effective speed 3.3Mhz with much slower memory and I would say same approach could give effective speed around 5MHz for Sam, with 6MHz Z80 and 100 ns DRAMS.
Or they could use 64kb*4 DRAM chips and split memory space into two parts: one shared by both CPU and video and second accessible by Z80 only, on full speed.
They could even split memory space into three 64KB parts, one dedicated to CPU, and two accessible by both CPU and video. Video chip could select which one 64KB area will be used as source of video data, while the other - backbuffer - could be accessed by CPU at full speed. When CPU would be done with backbuffer, video chip would switch source of video data. That way Z80 would have always 64KB of fast memory and fast access to backbuffer. With 6MHz Z80 one could increase screen size to 12KB - 16KB and have CPC (or similar) graphic capabilities with roughly same cpu power per pixel ratio as Spectrum has.
But it doesn't matter, I just wanted to point that dedicated 2D hardware was never the only option. At all, DOOM stomped everyone with dead simple VGA and raw power of 386.

Maybe @1024MAK could explain what is wrong with Sam Coupe, he seems to know everything about hardware.

[Stefan]

Honestly, I don't know what exactly is wrong with Sam timing, Amstrad was able to make 4Mhz Z80 run on effective speed 3.3Mhz with much slower memory and I would say same approach could give effective speed around 5MHz for Sam, with 6MHz Z80 and 100 ns DRAMS.
Or they could use 64kb*4 DRAM chips and split memory space into two parts: one shared by both CPU and video and second accessible by Z80 only, on full speed.

I thought the effective speed for Mode 4 worked out at approx 4.8MHz for the SAM, which works out at 4.8/6.0 = 80% which is pretty close to the Amstrad's 3.3/4.0 = 82.5%. The massive problem with mode 4 is that it uses 24K which is four times the video memory of a ZX Spectrum.

[catmeows]

I thought the effective speed for Mode 4 worked out at approx 4.8MHz for the SAM, which works out at 4.8/6.0 = 80% which is pretty close to the Amstrad's 3.3/4.0 = 82.5%. The massive problem with mode 4 is that it uses 24K which is four times the video memory of a ZX Spectrum.

OH, ok. I read somewhere that effective speed of Sam Coupe was "slightly faster than Spectrum" and I imagined much lower figure. My mistake, thanks.

[Pegaz]

Even the best ATM2/ZX-Evo games, blow away Next exclusive titles.
I expected a lot from Wonderfull Dizzy, but he didn't show up either.
But, regardless of the graphics, my main problem is that these games don't have any Spectrum look&feel.
If I want to play games like that, there are tons of them for Amiga/ST, much better than they will ever be on Next.
After almost five years of existence, the support of other cores is desperate, especially compared to other popular fpga devices (Uno, Mister etc).
That’s why I’m a big fan of the @Lethargeek project, which is not just a software upgrade for the emulator, but is hardware-based idea.
Spectrum games have retained their original look and charm, just received a fine and discrete facelift.
If I want to play classic Spectrum games, then I especially don't need Next for that.
As one smart man said before, Next is more or less an expensive fancy keyboard, when you have to wait until you become gray-haired and retire...

[PeterJ]

Can we avoid this becoming a Next bashing thread. Surely it can't be 12 months since the last one! They never end well....

[catmeows]

I thought the effective speed for Mode 4 worked out at approx 4.8MHz for the SAM, which works out at 4.8/6.0 = 80% which is pretty close to the Amstrad's 3.3/4.0 = 82.5%. The massive problem with mode 4 is that it uses 24K which is four times the video memory of a ZX Spectrum.

OH, ok. I read somewhere that effective speed of Sam Coupe was "slightly faster than Spectrum" and I imagined much lower figure. My mistake, thanks.

From Wikipedia: "SAM Coupé's CPU effectively ran only around 14% faster than the ZX Spectrum CPU"
... So Is Wikipedia wrong in this case ?

[kegnkiwi]

Well i created this thread and I thought it was going to be a simple question to answer. I read around the net that the chip could handle graphics up to about the level of the game boy. I expected it to handle better but I guess I was wrong. Don't get me wrong i love the n-go (next clone) and think its a great computer. It would have been nice to be able to play games up to mega drive and n64 games similar to what a pi 4 cant do, but I guess it cannot do that.

[Stefan]

OH, ok. I read somewhere that effective speed of Sam Coupe was "slightly faster than Spectrum" and I imagined much lower figure. My mistake, thanks.

From Wikipedia: "SAM Coupé's CPU effectively ran only around 14% faster than the ZX Spectrum CPU"
... So Is Wikipedia wrong in this case ?

Without an actual benchmark, I think we are just going to be quoting sources

http://eab.abime.net/showthread.php?p=1045138 4.8MHz
https://www.old-computers.com/museum/co ... st=1&c=545 4.5MHz

Simon has a nice article about contention at https://simonowen.com/sam/timings/

[catmeows]

Simon has a nice article about contention at https://simonowen.com/sam/timings/

That table explains a lot. Thanks.