There is a lot of "fuck" said today...
sorry about that
Yes, lots of aspies here!!
.
@ tvalenca: Why apologize? You weren't the one saying it.
General appeal: Lately, some people seem to need to clean up their attitude a bit.
If you feel the shoe fits, it's probably indeed referring to (amongst others) you, and it's advisable to do so. It's not hard, really.
@ tvalenca: Why apologize? You weren't the one saying it.
General appeal: Lately, some people seem to need to clean up their attitude a bit.
If you feel the shoe fits, it's probably indeed referring to (amongst others) you, and it's advisable to do so. It's not hard, really.
Anyone feeding the flames with gasoline should be responsible as well. That was my feeling, so I apologized.
Nice... is this existing hardware or only a design?
ARM + FPGA is a nice combo but begging for integration. Any chance of porting this eg. to a Xilinx Zynq part (say, a board like the ZynqBerry) or an equivalent Altera SoC/FPGA part?
Personally on such a board I'd prefer as much as possible of the MSX to be done in FPGA, with the ARM used for housekeeping jobs like bootup / FPGA config / helping to implement some peripherals etc. Emulating parts of the MSX on the ARM is possible of course. But if I want software emulation I'd rather look elsewhere (PC, phone / tablet etc).
Nice... is this existing hardware or only a design?
ARM + FPGA is a nice combo but begging for integration. Any chance of porting this eg. to a Xilinx Zynq part (say, a board like the ZynqBerry) or an equivalent Altera SoC/FPGA part?
Personally on such a board I'd prefer as much as possible of the MSX to be done in FPGA, with the ARM used for housekeeping jobs like bootup / FPGA config / helping to implement some peripherals etc. Emulating parts of the MSX on the ARM is possible of course. But if I want software emulation I'd rather look elsewhere (PC, phone / tablet etc).
Nice... is this existing hardware or only a design?
This four layer board design was done in Altim designer but still not tested on existing hardware although there is a prototype.This board was uploaded to oshpark (https://www.oshpark.com/profiles/albatroz) but is still waiting for my purchase :(
I started this project 4 years ago and builded a prototype using a STM32F4DISCOVERY(Arm cortex M4) board and a ALTERA FPGA board "DE0 nano". I coded some "C" code on ARM to integrate with the original MSX hardware. A LUA(http://www.lua.org) interpreter shell and some functions like vpoke,poke,play,... was born on MSXARM. Here some LUA scripts that run on prototype:
https://github.com/rogeriomm/msxarm-filesytem/blob/master/co...
https://github.com/rogeriomm/msxarm-filesytem/blob/master/co...
This demo shows the openmsx emulator + ARM Cortex M4 emulator running just how it is already run on the MSXARM prototype:
https://www.youtube.com/watch?v=bEIdZhM_kcA
Here is a openmsx source code patched to run my MSXARM hardware emulator as showed in above video:
https://github.com/rogeriomm/openmsx
ARM + FPGA is a nice combo but begging for integration.
The MSXARM prototype has a FPGA core that integrates the ARM memory controller and the FPGA and the real MSX console. It's was coded in Verilog HDL. My implementation is optimized to use the ARM memory burst mode at 60Mhz and have a cache system. I implemented a FPGA core to interface with the MSX bus. It's running on the prototype and was validated on Modelsim HDL simulation tool.
The interface with the MSX bus on the prototype uses a CPLD and the source code is opensource. It's uses a multiplexed bus interface with parity check:
https://github.com/rogeriomm/msxarm-breakout-integration/blo...
I designed a MSX cartrige PCB board to interface the MSX and the FPGA. The Altium design project is opensource too(only tested on prototype)
https://github.com/rogeriomm/msx-slim-breakout-board-pcb Slim version
https://github.com/rogeriomm/msx-fat-breakout-board-pcb Fat version
https://www.oshpark.com/profiles/albatroz
Any chance of porting this eg. to a Xilinx Zynq part (say, a board like the ZynqBerry) or an equivalent Altera SoC/FPGA part?
A Xilinx Zynq is a nice device to be used on MSXARM design, but the Zynq BGA package is too hard to produce, so an existing board would be the best choice. Maybe a board like this one running a embeded real time OS(FreeRTOS) https://www.crowdsupply.com/krtkl/snickerdoodle
The Z80/R800 emulator is running on MSXARM prototype at 50Mhz. The ARM running at 667Mhz+8 pipeline stages on Xilinx Zynq can run Thumb2 mode(The emulator was coded in ARM thumb2 assembly), so I think it can run the Z80/R800 emulator at > 200Mhz.
Personally on such a board I'd prefer as much as possible of the MSX to be done in FPGA, with the ARM used for housekeeping jobs like bootup / FPGA config / helping to implement some peripherals etc. Emulating parts of the MSX on
the ARM is possible of course.
In the begining of the MSXARM design I was thinking to run the Z80/R800 on FPGA(using a modified version of T80 core), but the complexity of integrating this one with the existing real Z80/R800 on MSX(MSX don't have DMA) changed my way of thinking. Anyway this is psychology(emulation is evil) issue only, because using a Z80/R800 emulator running on ARM dont change anything on the final design in terms of Z80 cycle accuracy and latency issues(I'll explain this later). It changes just how fast the Z80/R800 runs and the psycology effect. Maybe 100Mhz on a FPGA Xilinx Spartan 6, 50 Mhz on ARM STM32F4(Cortex M4) and 80Mhz on ARM STM32F7(Cortex M7)
But if I want software emulation I'd rather look elsewhere (PC, phone / tablet etc).
---+ Short answer (Black/white answer):
The MSXARM design has the word "emulation" in the specification. So it's just another hardware emulator as openmsx(great emulator that is helping me build the MSXARM), so one would prefer a PC emulator that is free. I cannot do anything about this line of thinking, but if you continue to read, I'll try to explain my point.
---+ Long answer:
We all know snow but eskimo have several names to several types of snows. Probably they have some negative(threatening life) psychological effect on some types of snow as some have on all types of emulation techniques. In the same way the emulation word alone don't really describe several types and quality of emulation.
Below I'll try to explain some known emulation techniques(with word qualifiers):
------+ "Bloated General purpose OS(Windows/Linux/NetBSD...) + full emulation"
Here all hardware is emulated: Z80/R800, VDP, PPI, sound, disk, ....
The operation system is bloated. There are several processes and hardware devices drivers competing the processor, so there are latency issues.
Examples:
openmsx running on Microsoft Windows
http://openmsx.org/
------+ "Reconfigurable Hardware + Full emulation" Reconfigurable hardware = FPGA or CPLD
Some consider real hardware probably to don't associate with a negative psychological effect. I think the "emulation" word alone is too weak to decide if is or isn't emulation. Just add some words qualifiers and all cleans up.
Examples: OneChip MSX (FPGA)
https://en.wikipedia.org/wiki/1chipMSX
------+ "Reconfigurable Hardware hybrid emulation"
FPGA/CPLD + real hardware
Examples:
- Minimig (FPGA + real Mototola 68000 processor)
https://en.wikipedia.org/wiki/Minimig
- One chip MSX + cartridge
------+ "Embeded real time OS + reconfigurable hardware zombie mode hybrid emulation" Hybrid = real hardware(VDP,PPI,sound,cartridge...) + emulation
This is designed by me and I dont know any device running this way.
Here only the Z80/R800 is emulated. The MSX don't have DMA ,them the Z80 is transformed on a zombie(In fact the real Z80 only execute I/O intructions and NOP instructions). Others devices can be emulated but it's optional. One can choice to use the real hardware on real MSX console(keyboard,VDP,sound,cassete,printer,floppy disk,...) or cartridge(IDE interface, GFX9900...).
In the next post I'll describe(low level concepts) how the ARM (WALKING DEAD VIRUS :) ) controls the MSX Z80 ZOMBI(WALKING DEAD HOST :) ) using a clever syncronization technique to run Z80 code on ARM 100%(not 99.99%) cycle accurate with the real Z80! It's 100% accurate, that one can load a program from cassete connected on MSX, running the Z80 on ARM!
The image below show how the MSX2++ can be upgraded to TurborGT. In the meantime I successfully downgraded the Turbor R GT to MSX 2++ using the MSXARM simulator(openmsx + ARM simulator MSXARM SDK ). I working now on the upgrade to TurboR using the MSXARM simulator(openmsx + ARM simulator MSXARM SDK ). I'll post a demo video in some weeks!
TODO.............. TO BE CONTINUED on may/2 ...............