Autor
| One chip MSX improvement project
|
HRA! msx lover Mensajes: 105 | Publicado: Mayo 06 2008, 16:49   |
If I improve VDP-command.... (It doesn't do.  )
The VDPcommand completion interrupt function is added.
And, the queue is achieved by CPU program.
I want to solve the interchangeability problem ahead of that.
|
|
Latok msx master Mensajes: 1719 | Publicado: Mayo 06 2008, 16:52   |
I'm already confused. Should I update my 1chipMSX with the KdL-updates which are based on HRA!-releases or is it save to directly use the HRA! updates since he's active on this board now as well.......
And in case of the latter.....What's KdL his future involvements......
And how will MicroTech his work fit into all this......
We seriously need some kind of 'official' development team. The sooner the better!!!!!
|
|
SaebaMSX msx freak Mensajes: 244 | Publicado: Mayo 06 2008, 17:06   |
Quote:
| We seriously need some kind of 'official' development team. The sooner the better!!!!!
|
Hey tokko!
Why don't you create a TODO list? :-)
Right now I have my OCM with latest KdL version for some tests but as I have the PLD files in my SD card I am switching from HRA to KdL and then older versions if necessary. Latest HRA version corrects some things with sprites which do it really worth to update to that version.
I want to help everybody here who are developing for OCM, but it would be nice to keep some kind of tracker with achieved/todo modifications. The problem is... who is going to do that?  |
|
HRA! msx lover Mensajes: 105 | Publicado: Mayo 06 2008, 17:39   |
Quote:
|
Why don't you create a TODO list? :-)
|
Is it good in this?
TODO List:
(1) H-SYNC/V-SYNC Timing bug ( RuneMasterII title demo freeze)
(2) Sound bug? ( Xak and Fray demo freeze and broken sound)
(3) VDP Command(NormalVDP Mode) speed adjustment
(4) R800 mode of CPU (for turboR compatible)
(5) S1990 emulation (for turboR compatible)
(6) 8bit PCM sound (for turboR compatible)
(7) DIP S/W status read/write from CPU
Already fixed (next release)
(1) display right edge chop fixed.
|
|
SaebaMSX msx freak Mensajes: 244 | Publicado: Mayo 06 2008, 18:19   |
Quote:
|
TODO List:
(4) R800 mode of CPU (for turboR compatible)
(5) S1990 emulation (for turboR compatible)
(6) 8bit PCM sound (for turboR compatible)
|
Do you think OCM can handle complete turboR emulation? I'm impressed. 
Of course having all the bugs fixed first (MSX1-MSX2 and if they are correct then 2+) is mandatory IMO.
But having turboR emulation is a really good candy...  |
|
HRA! msx lover Mensajes: 105 | Publicado: Mayo 06 2008, 18:31   |
Quote:
|
Do you think OCM can handle complete turboR emulation?
|
It is not possible to promise to be able to do.
However, the possibility is not 0.
It takes time to achieve it.
However, I want you to look forward.  |
|
SaebaMSX msx freak Mensajes: 244 | Publicado: Mayo 06 2008, 21:06   |
Quote:
| It takes time to achieve it.
However, I want you to look forward. 
|
I can imagine it won't be easy... that would be cool, my third turboR but now inside OCM!
By the way, I've been testing some keyboards with rare behaviour (all of them 105 keys, Spanish keyboard):
1. No diagonal moves + SPACE will work.
2. Logitech Keyboard (Y-SU45). This is the one I use in PC and is not OCM compatible. I can start typing after booting, but just after I write some keys the OCM keeps writing letters on the screen (related to the ones I've pressed). In fact, I can replace the keyboard that it will continue doing that. I don't think it uses special drivers or something (I use this in Linux too).
3. Diagonal moves + SPACE works (strange, this is the worst keyboard I have and the one which works better)
I heard from another user that his keyboard can't do diagonal moves + space with OCM while it does in PC. So these movements are working in PC.
Which could be the reason then? |
|
KdL msx user Mensajes: 59 | Publicado: Mayo 06 2008, 22:14   |
Latok:
-> OCM-PLD v2.2b is a MSX2 model based on original sources + HRA!, caro & KdL (me) improvements:
it have CMT, SLOT1&2 keyboard toggles, Led for all DIP-SW, etc. etc.
-> new MSX2+ model by HRA! is a best remodelled 1chipMSX firmware that it's in progress now...
|
|
KdL msx user Mensajes: 59 | Publicado: Mayo 06 2008, 22:27   |
Freeze bug repport:
- DIX (black screen)
- SONYC (island map)
- MSX 20th Anniversary Demo (red-white dancer screen)
|
|
HRA! msx lover Mensajes: 105 | Publicado: Mayo 07 2008, 04:03   |
bug report for original OCM in Japan.
http://free.flop.jp/1chipmsx/index.php?%E5%8B%95%E4%BD%9C%E7%A2%BA%E8%AA%8D
Cartridge:
Puzzle Panic: NG: MSX1 exclusive use. It is not possible to play even with genuine MSX2.
Galaxian: NG: MSX1 exclusive use. It is not possible to play even with genuine MSX2.
FomationZ: NG: The display collapses immediately after beginning of the game.
ZanacEX: ?: The display collapses after it demo.
Moero! Nettou-yakyu'88: ?: The noise mixes with the voice.
DragonSlayerIV(MSX2): ?: When the SD card is enable, it doesn't start.
Disk:
Rance2: NG: Freeze
Sekai-de-ichiban-kimi-ga-suki!: NG: It doesn't start.
Nobunaga-no-yabou-sengoku-gunyuuden: NG: It doesn't start.
Nobunaga-no-yabou-busyo-huuunroku: NG: It doesn't start.
Europe-Sensen: NG: It doesn't start.
L'EMPEREUR: NG: It doesn't start.
Snacher: ?:
Gakuen-senki: NG:
Feed back: ?: Illegal sound.
Barunba: ?: Freeze
Hacchake-ayayo-san-2: NG:
BURAI Gekan: NG: It doesn't start.
Jyan-borg-SUZUME: NG:
Princess Maker: ?: It comes to sounding it when the scene changes.
Fray: ?: no sound
|
|
HRA! msx lover Mensajes: 105 | Publicado: Mayo 07 2008, 11:33   |
New Update PLD:
http://www5d.biglobe.ne.jp/~hra/note/onechipmsx/files/emsx_top_20080507_001.zip
Updates:
(1) Mapper RAM changed to 4MB.
(2) Display right edge fixed.
(3) OPLL wait deleted :-(
(4) ToDo.txt added.
Quote:
|
- MSX 20th Anniversary Demo (red-white dancer screen)
|
It is PAL Monitor only. (VGA Monitor is not supported.)
Memo:
The VGA monitor output compulsorily becomes NTSC mode.
Because the VGA monitor is 60Hz.
It is an extra that the software only for PAL moves by the VGA monitor.
Interchangeability is unwarrantable.
|
|
HRA! msx lover Mensajes: 105 | Publicado: Mayo 07 2008, 13:19   |
|
|
KdL msx user Mensajes: 59 | Publicado: Mayo 07 2008, 13:44   |
Quote:
|
--------------------------------------------------------------------------------
- MSX 20th Anniversary Demo (red-white dancer screen)
--------------------------------------------------------------------------------
It is PAL Monitor only. (VGA Monitor is not supported.)
Memo:
The VGA monitor output compulsorily becomes NTSC mode.
Because the VGA monitor is 60Hz.
It is an extra that the software only for PAL moves by the VGA monitor.
Interchangeability is unwarrantable.
|
...mmmh?! with original VDP model of OCM-PLD v2.2b it work fine with VGA Monitor at 60Hz forced... why??
|
|
HRA! msx lover Mensajes: 105 | Publicado: Mayo 07 2008, 14:13   |
Quote:
|
...mmmh?! with original VDP model of OCM-PLD v2.2b it work fine with VGA Monitor at 60Hz forced... why??
|
In OCM, there are a variety of timing bugs.
Working with VGA Monitor is not necessarily correct.
(Working with VGA Monitor might be correct.)
VGA Monitor mode is a function not provided in genuine MSX.
|
|
MicroTech msx lover Mensajes: 108 | Publicado: Mayo 07 2008, 15:02   |
@ HRA! & D-Tail:
I think "BD technology" can improve performances in applications (demo/games) which make massive use of vdp command engine.
I'm thinking to a game in which 2 video pages are used (I'm actually working on it but these considerations can be extended to any similar application).
During a "frame period" cpu has to:
1) show display page
2) prepare active page:
2A) clear active page
2B) calculate 3D transformations
2C) translate 3D primitives to 2D primitives
2D) prepare (queue) corresponding vdp commands
2E) feed vdp with queued commands (here cpu wastes lot of time waiting vdp to become ready)
3) wait vdp/syncronization, swap active/display page, goto 1
Even "pipelining" the code (steps 2B, 2C, 2D prepare a frame while step 2E works on data related to the previous frame) cpu spends time to poll vdp and code results constellated with call to the poll routine.
Although this could be avoided with the "interrupt on end of command" feature, I think cpu would still spend lot of time to enter/exit from isr (in my scenario a frame is rasterized with 200 vdp commands).
|
|
|
|
|