Proyecto ZX-Uno, clon de spectrum basado en FPGA

[cheveron]

And cheveron, can you tell me what is your more efficient 6x8 routine to do the comparision?

Your routine is more efficient. But mine isn't far off it without using pre-rotation.

[antoniovillena]

And cheveron, can you tell me what is your more efficient 6x8 routine to do the comparision?

Your routine is more efficient. But mine isn't far off it without using pre-rotation.

Of course, I will compare 3 routines in 256x192 mode (normal ZX Spectrum): your 6x8 without prerotated, my 6x8 rotated and the fastest 8x8 that I can write. It will take me some time. Of course I'll fill all the screen with strings to do the results more visible.

[cheveron]

And cheveron, can you tell me what is your more efficient 6x8 routine to do the comparision?

Your routine is more efficient. But mine isn't far off it without using pre-rotation.

Of course, I will compare 3 routines in 256x192 mode (normal ZX Spectrum): your 6x8 without prerotated, my 6x8 rotated and the fastest 8x8 that I can write. It will take me some time. Of course I'll fill all the screen with strings to do the results more visible.

I wouldn't bother, for two reasons. First, the code in SE Basic IV is optimized for the a 512x192 screen. Second, you're not taking into account the stuff that really slows printing down like dealing with OVER, INVERSE, keeping track of the print position and so on. A clean 8x8 driver will always be fastest. But the standard Spectrum ROM isn't clean.

[antoniovillena]

I wouldn't bother, for two reasons. First, the code in SE Basic IV is optimized for the a 512x192 screen.

I can do it for 512x192 and count the cycles with Ticks.

Second, you're not taking into account the stuff that really slows printing down like dealing with OVER, INVERSE, keeping track of the print position and so on. A clean 8x8 driver will always be fastest. But the standard Spectrum ROM isn't clean.

But taking account OVER, INVERSE, etc... won't advantage the 6x8 driver against the 8x8 one. It will be slower in both cases. The point is that in whatever scenario that you choose 8x8 font are faster than 6x8, I think that it's at least 500% faster. I have compared recently in the BIOS for the ZX-Uno and quickly improve to a rotated version because it was very very slow.

[cheveron]

...whatever scenario that you choose 8x8 font are faster than 6x8, I think that it's at least 500% faster.

Depends how it's written. The original ROM code is amazingly slow.

I have compared recently in the BIOS for the ZX-Uno and quickly improve to a rotated version because it was very very slow.

The BIOS is written in Z80?

[antoniovillena]

Depends how it's written. The original ROM code is amazingly slow.

Ok. A bad written 8x8 driver can be as slow as the best written 6x8 one, but if we want compare we must be fair. As I know SE BASIC IV is not the original ROM, it's a rewritten from scratch.

The BIOS is written in Z80?

Yes

[cheveron]

Depends how it's written. The original ROM code is amazingly slow.

Ok. A bad written 8x8 driver can be as slow as the best written 6x8 one, but if we want compare we must be fair. As I know SE BASIC IV is not the original ROM, it's a rewritten from scratch.

It's not that the original ROM is bad, it's just that it has to serve the screen and the printer. Like the original ROM, SE Basic IV is derived from the ZX81 ROM, which thanks to the generosity of John Grant is available under the GPL license.

The BIOS is written in Z80?

Yes

I suppose it makes sense to write for the target CPU. What things will be configurable?

[antoniovillena]

I suppose it makes sense to write for the target CPU. What things will be configurable?

Not much. Basically you can manage different ROMs and on which you'll boot. It's in the official repository, in a folder called /firmware. You can execute firmware.rom as a 48K ROM.

[cheveron]

I suppose it makes sense to write for the target CPU. What things will be configurable?

Not much. Basically you can manage different ROMs and on which you'll boot. It's in the official repository, in a folder called /firmware. You can execute firmware.rom as a 48K ROM.

Where is the official repository?

[antoniovillena]

Where is the official repository?

I'm sorry. Look at the bottom of the first message in this thread:

http://zonadepruebas.com/viewtopic.php?f=26&t=4927

[cheveron]

Where is the official repository?

I'm sorry. Look at the bottom of the first message in this thread:

http://zonadepruebas.com/viewtopic.php?f=26&t=4927

That's pretty nifty. I'm not clear on how you add ROMs from the BIOS though. I assume you're not going to ship it with the BSkyB ROMs included?

[antoniovillena]

That's pretty nifty. I'm not clear on how you add ROMs from the BIOS though. I assume you're not going to ship it with the BSkyB ROMs included?

By tape or by SD (FAT32 LFN formatted), but doesn't work because it's in development. Yes, the included ROM is only the SE BASIC.

[cheveron]

That's pretty nifty. I'm not clear on how you add ROMs from the BIOS though. I assume you're not going to ship it with the BSkyB ROMs included?

By tape or by SD (FAT32 LFN formatted), but doesn't work because it's in development. Yes, the included ROM is only the SE BASIC.

Awesome. Well I'm really looking forward to getting my hands on one now. Having seconds thoughts about my choice of keyboard colors though. Maybe this would be better:

[hikoki]

Idea peregrina para el teclado que no sé si tiene mucho sentido
El teclado sería una app para tablet con las teclas ocupando toda la pantalla, la ventaja sería que el diseño sería muy parecido al original, posibilidad de elegir diferentes teclados, se emularía el teclado utilizando un dispositivo táctil a pantalla completa, una tableta de 10 pulgadas daría mucho de sí y en una de 7 pulgadas se podría utilizar algún tipo de lupa si tocas una tecla, la tecla quedaría agrandada, si la vuelves a tocar se pulsaría dicha tecla.
Podría hacerse un interfaz tableta/zx-uno ?

[mcleod_ideafix]

Podría hacerse un interfaz tableta/zx-uno ?

Técnicamente se puede, por supuesto. Ahora bien, para poder abarcar tablets tanto Android como iOS, y para no tener que pagar royalties a Apple por sacar un aditivo hardware para el iPad, la única forma que veo de interfaz es... a través del conector de auriculares. La app, para cada tecla pulsada o soltada, generaría un código similar a los make/break codes de un teclado PS/2, y lo enviaría codificado como sonido, similar a los sonidos de carga del Spectrum, al ZX-Uno, en donde la FPGA decodificaría el stream convirtiéndolo en un código.

También se puede hacer que lo que mande la app cada vez que se pulsa o suelta una tecla sea el estado completo de la matriz, es decir, 40 bits. De esa forma la decodificación en la FPGA es mucho más sencilla.

Si tu pretensión era sólamente abarcar tablets Android, imagino que puede usarse el puerto USB OTG de estos dispositivos y conectar ahí un FT232 o un FT245 para enviar datos por USB a la FPGA.

Ahora bien, lo que no sé es qué latencia puede tener eso. Es: tocar la pantalla + tiempo desde que se detecta pulsación hasta que se informa a la app + tiempo que la app necesita para enviar la información a la FPGA.