OCM-PLD Pack 2.2

Project pending

https://sourceforge.net/projects/ocm-pldpack/

KdL> Restored original VDP model: screen 0 blink problem is fixed now!
I have overlooked all versions of files VDP, but has not found
in one of them of corrections concerning problem BLINK.
But I have found the reason of this problem - mistake in a file text12.vhd
The fixed version can be taken here: www.caro.k66.ru/files/text12.zip

Hi Caro, you wrote:

By caro on March 16 2008, 11:51
Edwin wrote:
---
I tried to build the so called "Unofficial Release", but it won't fit in the FPGA. The thing takes up 18k LEs.
---
in the file scc_ram.vhd
type ramdb is array( 0 to 255 ) of std_logic_vector( 7 downto 0 );
change to
type ramdb is array( 7 downto 0 ) of std_logic_vector( 7 downto 0 );
and build to OK.

but this correction, is a valid correction???

KdL write: "but this correction, is a valid correction???"

No this correction, is not a valid correction. I was mistaken.

KdL write: "do you have a disktest.dsk to compare with original version?"

No.

KdL write: "Yes, my v2.2 use original 'text12.vhd' again but it work fine
because I've resolved BLINK problem modifying the Fitter Settings
optimizations of Quatus II Web Edition."

I do'nt think, that it can tesolved problem correctly.
Look original file text12.vhd
Pay attention to a signal BlinkPeriodCount, which determines time Blink ON and Blink OFF.
It only is cleared, but it is not considered and counted.

in this release Hra have:

- GRAPHIC123M.VHD is modifing, but continue...
- There is a dis-assembly result of IPLROM in "src/peripheral/test/iplrom.asm".

I have received the answer from HRA:
" Your scc_ram.vhd was seen.
I think that it is a very good correction!! "
The fixed file can be taken here: www.caro.k66.ru/files/scc_ram.zip

New updated PLD from HRA:
http://www5d.biglobe.ne.jp/~hra/note/onechipmsx/files/emsx_top_20080320.zip
For what to save 370 LE, hara has removed Debug Window.

Wow!
Another update:
http://www5d.biglobe.ne.jp/~hra/note/onechipmsx/files/emsx_top_20080321.zip

Hello.

I am concentrating on the shape-up of VDP now

My target is "Compatible v9958" and "Some new features. "

Some preparations are necessary to achieve it.

1. Empty capacity of FPGA is expanded.
2. The crosswiring circuit is untied.

Time is necessary for this work.
Please wait patiently

A new bug was found yesterday.

Bit 6 of S#0 is always 0.
It is a flag that notifies the disappearance of sprite.
In ALESTE2 etc. , it influences the sprite display and the processing speed.

The signal already exists.
However, If it is used, illegal timing is generated.
(The display falls into disorder. )

It is thinking about measures now.
-------

* turbo-blitter
Hmm, I think that hope is thin.
However, I will think a little.

* More than 128KB of VRAM
This thinks that it can do.

HRA> Thanks for joining us and giving some first hand descriptions of what is going on with the 1chipMSX development.

NYYRIKKI> I don't think the problem is with the slot layout and memory. The functionality for this is already there, obviously. The problem is more like the storage of the ROM images. The current roms already take up half of the flash rom and there is not much space left for more. To do this you would have to rely on the SD card for solely (not the most robust solution) or implement a partial load from SD. This would be the preferable solution. In fact, it could be used to load all non-critical roms.

Oh!

> 10 SCREEN 5:X=0:Y=0:I=&H2121

10 SCREEN5: x=0: y=0: i=&H2121

Oh, I forgot PUT KANJI-command. (I don't use KANJI that much ) I just noticed that CALL KANJI and other KANJI related CALL commands were missing...

Maybe some of the internal memory could be anyway used to store RTC memory? That should not take that much memory...

(Sorry if I suggest something that has been already done. I try to keep the system up and running at least for a while before I put it to condition where it does not boot anymore )

Please make the program that installs KANJI-BASIC from the SD card
I'll do it while waiting, if you make me RAM that can be protected to slots 0-1 & 0-3 Pure RAM is a bit bad option as some software may actually think that this RAM is meant as primary memory. We need something like MSX tR DRAM-mode... (In tR I many times replace KANJI-BASIC ROM with X-BASIC when I develop on it. This makes it possible to leave low RAM for Super-X )

Actually I'm currently doing software workaround to implement reset proof RTC banks 1-3 (needs manual save to memorycard) How ever I still think, this should be fixed in hardware...

All system-ROM of "1chipMSX" is put on ESE-RAM.

Boot sequence of 1chipMSX:
(1) run IPL-ROM (512byte: SLOT3-3)
At this time, ROM other than "SLOT3-3" are empty.
(2) ROM data is downloaded from Configration-ROM to ESE-RAM by IPL-ROM.
(3) IPL-ROM jumps to 0000H of "SLOT0-3" at the end.
(4) At this point, MSX-System starts.

Therefore, "SLOT0-1" is rewritable
However, because nothing is connected with "SLOT0-3", it is not rewritten.

Please refer to IPL-ROM for the method of how to rewrite it of SLOT0-1.
IPL-ROM is only 512 bytes program for Z80.

Sorry, mistake in (3).

(3) IPL-ROM jumps to 0000H of "SLOT0-0" at the end.

At present, nothing is connected with "SLOT0-3".
However, RAM will be connected in the future

New update PLD:
http://www5d.biglobe.ne.jp/~hra/note/onechipmsx/files/emsx_top_20080330.zip

(1) ESE-RAM(256KB) of MegaSD is increased to 512KB.
(2) RAM of MegaSD is connected with "SLOT0-1" and "SLOT0-3".
(3) Experiment circuit (R#26,R#27) for v9958 is added.

These are the untests all ;)

information:
SLOT0-0: MainROM = MegaSD ESE-RAM Bank 8-11 (8KB * 4banks = 32KB)
SLOT0-1: Free ROM1 = MegaSD ESE-RAM Bank 32-39 (8KB * 8banks = 64KB)
SLOT0-2: Ext. ROM = MegaSD ESE-RAM Bank 12, 13 (8KB * 2banks = 16KB)
SLOT0-3: Free ROM2 = MegaSD ESE-RAM Bank 40-47 (8KB * 8banks = 64KB)
SLOT3-1: Sub ROM = MegaSD ESE-RAM Bank 14, 15 (8KB * 2banks = 16KB)
SLOT3-2: DiskBASIC = MegaSD ESE-RAM Bank 0-7 (with ESE-RAM[8KB * 64banks) controller and SD Card controller)
KANJI ROM: MegaSD ESE-RAM Bank 16-31 (8KB * 16banks = 128KB)
MegaSD ESE-RAM Bank 48-63 is free.

ROM including SLOT0-1 and SLOT0-3 is rewritten by way of SLOT3-2.

Memory map:
http://www5d.biglobe.ne.jp/~hra/note/onechipmsx/memory.htm

Emsx_top_20080330.zip has the bug.
The bug to which FM-BIOS disappeared was found.

For instance, if "call music" is executed, it becomes "syntax error".

It is debugging it now

The cause of the bug(emsxtop_20080330.zip) was ascertained.

The extended slot register at FFFFh was not considered.
It is not possible to return it to other SLOT0-X when changing to SLOT0-1 and SLOT0-3

I will release the correction version by the end of today.

New update PLD:
http://www5d.biglobe.ne.jp/~hra/note/onechipmsx/files/emsx_top_20080405_002.zip

Update:
(1) VDP HSYNC BUG FIX
--> The phenomenon of display blinking by "METEORITE KISS" etc. has been improved.

New update PLD:
http://www5d.biglobe.ne.jp/~hra/note/onechipmsx/files/emsx_top_20080406_001.zip

Updates:
(1) KANJI.VHD was rewritten. (11450LE --> 11439LE)
(2) The file composition of the archive was changed a little.

New update PLD:
http://www5d.biglobe.ne.jp/~hra/note/onechipmsx/files/emsx_top_20080406_003.zip

Updates:
(1) When 101/104 keyboards are used, the bug that was not able to input some
characters is corrected. (modified by caro)
(2) Experimental R#26/R#27 is corrected.
(3) The SDRAM controller is separated from EMSXTOP.VHD.
(4) The VDP access timing to the SDRAM controller is eased.
(5) Some test programs are added to the archive.

Information:
The operation of R#26/R#27 can be confirmed by executing "test_program/h_scroll" ;)
--> MSX-DOS, SCROLL.COM, and OCM.SC5 are copied onto the SD/MMC card.
--> And, SCROLL.COM is execute on OCM.

New update PLD:
http://www5d.biglobe.ne.jp/~hra/note/onechipmsx/files/emsx_top_20080407.zip

Updates:
(1) VDP R#25 bit0 (SP2) supported.
(2) added "test_program/h_scroll2".

Two screen horizontal scroll was achieved by this correction :D

EMSX_TOP that I release executes the simple test.

Test items:
(1) MSX-DOS2 must start.
(2) The display doesn't fall into disorder.
(3) Some test programs must operate normally.
(4) Some game software must start.

These are confirmed.
However, whether it operates normally by your OCM is uncertain.
Please use it by the self-responsibility.

Because I am busy on the weekday, the test more than this cannot be done.

I'm going to have to test this scroll register code soon!

HRA> Since you're very experienced with 1chipMSX code, could you also have a look in this thread about the 1cM sound quality?

Hi, any chances that all this changes works on the De1 board port?
I ask, because it has a lot less sdram.

Great Work!!

All current OCM code changes I have made and checking for DE1.
The amount of RAM, is now involved in the project OCM is 8 Mbyte, equivalent to the amount of memory DE1.
DE1 -> Altera Development and education board.
• http://www.altera.com/education/univ/materials/boards/unv-dev-edu-boards...
• Altera Cyclone II 2C20 FPGA with 20000 LEs
• Altera Serial Configuration deivices (EPCS4) for Cyclone II 2C20
• USB Blaster built in on board for programming and user API controlling
• JTAG Mode and AS Mode are supported
• 8Mbyte (1M x 4 x 16) SDRAM
• 4Mbyte Flash Memory
• 512Kbyte(256Kx16) SRAM
• SD Card Socket
• 4 Push-button switches
• 10 DPDT switches
• 8 Green User LEDs
• 10 Red User LEDs
• 4 Seven-segment LED displays
• 50MHz Oscillator ,24MHZ Oscillator ,27MHz Oscillator and external clock sources
• 24-bit CD-Quality Audio CODEC with line-in, line-out, and microphone-in jacks
• VGA DAC (4-bit R-2R per channel) with VGA out connector
• RS-232 Transceiver and 9-pin connector
• PS/2 mouse/keyboard connector
• Two 40-pin Expansion Headers

Ok, thank you for your answers.
That was all i need to know.

As Caro said , i was talking about Altera De1 Board, a development board with a more powerfull Fpga but 1/4 of Sdram os the OCM. I was afraid that this memory was not enought to get all your memory mapping changes.

Please continue with your work!!

Regards

In DE1 used IS42S16400 - synchonous DRAMs archieved high-speed data transfer using pipeline architecture and clock frequency up to 133 MHz.
My work PLD with source for DE1: www.caro.k66.ru/files/07_08_01.zip

This version has not yet include the current changes OCM project by HRA!, but it works.

Quartus II Web Edition Software v7.2 Service Pack 3 is out!!

https://www.altera.com/support/software/download/altera_design/quartus_we/dnl-quartus_we.jsp

Now I finally was brave enough to update.

It seems that the hardware is changed only after power is put off and back on. This makes me feel a bit better about updating.

I tried Pleasure Hearts with the latest version and the graphics (screen 4) seem to be corrupted for first 2/3 of the screen. This game was working fine before update.

It seems that the SCREEN 10-12 pictures are converted to 512 colors at the moment... Does not look good, but better than nothing... I also think that maybe you should already update VDP S#1 ID to V9958? The RGB colors in SCREEN 10/11 seems to be wrong also...

(Screen12) Laydock2 intro screen is fine with HRA! vdp model

OCM-PLD Pack 2.2b is out!!

http://www.webalice.it/gnogni/ocm/20080413_OCM-PLD_Pack_v2.2b_by_KdL.rar

v2.2b [2008.04.13] [KdL/HRA/caro's Updates!]

- Improved SCC_RAM module (by caro).
- Fixed RTC module (by HRA!).
- Fixed SCREEN0 blink timing (by caro/HRA!).
- Fixed OPLL VM2413 controller (by HRA!).
- Fixed low-pass filter of sound mixer (by HRA!).
- Added Slot1 selector on [SHIFT+F12] key.
- Added Slot2 selector on [SHIFT+Scroll Lock] key.
- Swapped DIP-SW7 and DIP-SW8 position.
- Restored VGA high luminance.
- Forced all VGA modes at 60Hz.
- VDP Debug Mode is disabled but source code contain it again.
- Updated DIP-SW User Manual [src_upgrade\doc\dipsw_v2x.htm].

Note:
To use MGLOAD & SCROM tools is very easy now with new [SHIFT+Scroll Lock] Slot2 selector key!! :RNFF:

New update PLD:
http://www5d.biglobe.ne.jp/~hra/note/onechipmsx/files/emsx_top_20080413.zip

Updates:
(1) R#27 BUG FIXED
(2) H-SYNC TIMING CHANGED
(3) IPL-ROM BOOT FROM SD/MMC IS 384KB SUPPORTED

Fixed:
(1) A sprite abnormal display (EMSXTOP 20080405_002.zip ... 20080412_002.zip) was corrected.(SpaceManbow etc.)
(2) KYOKUGEN might be able to play correctly.

Bugs:
(1) The sound of SCMD was not emitted.
(2) 5S bit bug.

FPGA empty capacity decreases, and the adjustment becomes difficult.....*_*

EMSX_TOP20080413.zip has improved the problem that some famous game software doesn't play.
The function of V9958 interchangeable register is obviously imperfect.

The problem of ID might have the cause in empty capacity of FPGA.
I want to improve the V9958 interchangeability function on the next weekend.

- border color in MSX2+ boot-logo is incorrect and makes masking sprites visible.
It seems that the color that should be 0 is now 5. This problem did not exist in original version of the hardware.

I checked the keymap.vhd and it seems that the keys that I'm missing from my keyboard are called #52 and #41 They seem to be present in the source, but not on my keyboard. Do you think that "Han/Zenkaku" could be redefined to be one of these as there is already select on F8?

(1) VDP-ID TESTED
VDP-ID was changed to V9958 and it started.
It was possible to boot it on MSX2 BIOS.
It change to V9958 in the next release.

(2) KEYMAP
It returns it to KEYMAP.VHD(23:52 04/04/2008 caro's 1st release) by the next release.

It doesn't release it today because the version tested now contains another
problem

I am working on the bug correction of the horizontal scroll register now.

The display of SpaceManbow broke when VDP-ID was changed to "V9958".
SpaceManbow checks VDP-ID.
And, if it is V9958, the horizontal scroll register is used.
It scrolls horizontally by using SetAdjust if it is V9938.

I had misunderstood to always use SetAdjust.

I tried Nyancle.
The SCREEN12 image was displayed

When the bug of the horizontal scroll register was able to be corrected, I
releases it.

> (1) VDP-ID was changed to V9958.

Works!

> (2) RTC was changed (RTC.VHD and EMSX_TOP.VHD)

It is still not power proof

> (3) It changes so that VDP R#26/R#27 may synchronize with the horizontal synchronizing
signal.

Seems to be working now

> (1) MSX2 + logo is still strange

The color problem is visible also with MSX2 boot screen.

Other problems:

- SCREEN 10/11 RGB colors do not work
- Keys #41 & #52 missing from keyboard (Can someone else confirm this?)
- Sprites do not work in SCREEN 10/11 and 12

> (2) RTC

Do you think it would be possible to assign 20 bytes permanent memory to store RTC banks 1-3 in future?

And writing the RTC info on a file in the sd card?

Version 20080419

The method of generating the scanning lines interrupt was corrected a little.
The bug not sounding SCMD[*1] was corrected.

*1: SCMD
http://cpu.dip.jp/3mhz/msx.html
SCMD is a music player by PSG, OPLL, and two SCC.

> (1) The bug of the background color and the sprite color in GRAPHIC5(SCREEN6) was corrected.
> --> A strange color around the MSX2/MSX2+ logo disappeared.

Actually it is not that strange... The color around should be 1 (01b) to make this in screen 6 you need to write 0101b to backround color register. with 16 color pallette this is color 5 that was visible in the logo before the fix.

Now it seems that also the logo is coming in! It is still looks a bit jerky (looks like if low 3bits would scroll to wrong direction) but it's much better

> (2) The sprite display in the YJK mode was corrected [** UNTEST **]

a bit better... Now the sprites work like in screen 8, but they should work like in screen 7

> a bit better... Now the sprites work like in screen 8, but they should work like in screen 7

I made the test program now. The phenomenon was confirmed.
It mends by the next release.

> How about continuing in an OCM-PLD thread in the forum?

Nice idea