ERROR: NO MEMORY

[kbenayed]

Hi, I just finished assembling the MSX Unit on the Enhance backplane (Yellow 80 pins)

I have the following boards:

-Stock RC2014 Processor and Clock (Both tested to work under RomWBW)

-Video: V9958 (Having trouble with ODB GBS-C where the picture is flickering, getting an OSSC) -Audio V1.9: Does not work with the SST chip installed even though slt 3-1 is shorted. Problem for another day. -Game Port -Memory

When I turn the system on with the ODB GBS-C, I get flickering picture, a blue background and a one liner error message: ERROR: MEMORY NOT FOUND

I doubled check all the solder points etc., I cannot seem to find a smoking gun, I appreciate any insights you might have troubleshooting this, thank you.

[dinoboards]

Hi mate,

Sorry to hear you having some issues getting the MSX software to boot up.

You don't mention in your list of boards, the PPI/Keyboard module. The PPI drives the keyboard, also drives the slot selections for RAM/ROM. Is it installed?

And are the SLT LOW and SLT HIGH jumpers shorted on both the PPI and Memory Modules?

Dean.

[kbenayed]

I apologize for overlooking to mention the PPI and the keyboard. They are both installed. I attached a picture.

I shorted the SLT LOW and SLT HIGH but I get no video post as configured (Unless I am doing something silly which is probably the case).

I do get a Video Post with ERROR: NO MEMORY if the music card SST ship is removed and if the SLT short cable is not installed.

[dinoboards]

Cool.

A couple things first:

1. Just remove the MUSIC Module from the backplane until we get a good boot up. It should boot up without the MUSIC module.
2. Since you are using the Yellow MSX backplane, you dont need to do the jumper wire between the PPI and Memory. Just short across of the jumper pairs - and use the backplane's lines. It may not resolve the issue - but it will simplify things a little.

I can send you a picture later to confirm.

The NO MEMORY message indicates that the ROM code is starting, but when it attempts to scan for RAM it fails. This can be due for a few reason - eg the RAM not installed. But it can also be due to the bank switching not working. So first thing is to check that the slot select signals are going from source (the PPI chip) to the Memory Module. Have a look at the schematic and follow the SLT LOW/HIGH signals and with a multimeter tracing through and see if you have a good path between the points. But also check they are isolated from other connections.

I do get a Video Post with ERROR: NO MEMORY if the music card SST ship is removed and if the SLT short cable is not installed.

This is a bit odd - and indicates something is getting crossed. the MUSIC card should not have any impact during initial boot up. Seems to indicate a cross connection or perhaps a short of something - and its kind of giving you a false positive. Certainty focus on getting a working boot with it fully removed.

If you have a digital probe (and or an oscilloscope), I would monitoring the RAM CS select signals during boot - do they toggle during bootup? Same with SLT-HIGH/LOW - do they toggle - check at both the bus lanes - but also at the input to the specific chips (again have a look at the schematics to identify the correct pins to inspect)

[kbenayed]

Thank you so much!, I do have an Oscilloscope, i will start the signal tracking as per your directions.

I appreciate sending a picture to confirm the shorts pattern. Thank you.

On Tue, Sep 24, 2024 at 12:37 AM Dean Netherton @.***> wrote:

Cool.

A couple things first:

1. Just remove the MUSIC Module from the backplane until we get a good boot up. It should boot up without the MUSIC module.
2. Since you are using the Yellow MSX backplane, you dont need to do the jumper wire between the PPI and Memory. Just short across of the jumper pairs - and use the backplane's lines. It may not resolve the issue - but it will simplify things a little.

I can send you a picture later to confirm.

The NO MEMORY message indicates that the ROM code is starting, but when it attempts to scan for RAM it fails. This can be due for a few reason - eg the RAM not installed. But it can also be due to the bank switching not working. So first thing is to check that the slot select signals are going from source (the PPI chip) to the Memory Module. Have a look at the schematic and follow the SLT LOW/HIGH signals and with a millimetre tracing through and see if you have a good path between the points. But also check they are isolated from other connections.

I do get a Video Post with ERROR: NO MEMORY if the music card SST ship is removed and if the SLT short cable is not installed.

This is a bit odd - and indicates something is getting crossed. the MUSIC card should not have any impact during initial boot up. Seems to indicate a cross connection or perhaps a short of something - and its kind of giving you a false positive. Certainty focus on getting a working boot with it fully removed.

If you have a digital probe (and or an oscilloscope), I would monitoring the RAM CS select signals during boot - do they toggle during bootup? Same with SLT-HIGH/LOW - do they toggle - check at both the bus lanes - but also at the input to the specific chips (again have a look at the schematics to identify the correct pins to inspect)

— Reply to this email directly, view it on GitHub https://github.com/dinoboards/yellow-msx-series-for-rc2014/issues/16#issuecomment-2370135292, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJFRLDSTBCYNMN7GZEXE5NDZYDUAXAVCNFSM6AAAAABOXAS5BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZQGEZTKMRZGI . You are receiving this because you authored the thread.Message ID: @.***>

[kbenayed]

Thank you for your feedback earlier on troubleshooting pointers. I finally have a post!, a startup logo and a clear screen. You have no idea how much this made my day !!! Thank you!

Current error is : ERROR: CALLED NON EXISTING BIOS

I have a Flash disk with nextor.sys, command2.com and the rest of the files. It appears to read the disk but does not try to boot it. Wondering if I need to update the rom...

I am trying to figure this out through the docs but another push would be great if you can! I am starting to believe this would work after a week of dark then very jerky screen.

[dinoboards]

That's great to see. What have you done resolve the previous errors?

I am not quite sure what the current state you have. You state your current error is:

Current error is : ERROR: CALLED NON EXISTING BIOS

Did you by chance mean: CALLED NON EXISTING BASIC?

The screenshot shows CBIOS booting, then stopping with Cannot execute a BASIC ROM

Also I am unsure, are you using the Compact Flash Module? If so, recommend removing that and attempting to boot just using the onboard ROM.

It does appear that the issue now is that the BIOS code has loaded, found some RAM - but then its not able to find/start Nextor (which it should as its embedded on the onboard ROM). But if Nextor fails to initialise itself, then the bios will go hunting from another startup - since CBIOS does not include BASIC - you can get this error.

Why Nextor would not load though, I am not sure. (Certaintly remove the Compact Flash if that is installed and give that a go)

If you have access to a programmer for the ROM (eg: a TL866 programmer) - then you can try download a ROM with basic included - ROM images can be downloaded from this repo's releases section (https://github.com/dinoboards/yellow-msx-series-for-rc2014/releases)

---

In regards to the pictures - sounds like you have it resolved. My images attached here, should just using a short wire to jumper the user bus lines. You can perhaps mount a shunt on each of the connector to achieve the same outcome

[kbenayed]

The error was indeed: Called non existing Basic. sorry about that. The issue previously was the jumpers between SLA_HIGH and SLA_LOW were not making good contact so that was that. Thank you for pointing me to the source of the issue.

The jerkiness of the display was related to the ODV-GDS-C , I swapped few VGA cable, one of them gave me stability thankfully.

I could not get basic to load no matter what with or without CF reader. I followed your advise and uploaded another ROM with basic support(msxsyssrc-rc2014-usa-without-rtc.rom), the system does boot into MSX Basic now at last :)

Last hurdle now before I hit the sound card is The system is seeing ghost keyboard input contentiously scrolling through the screen even when the Keyboard is not attached to the PPI. I will spend few cycles attempting to see if I wired anything incorrectly on the keyboard/PPI side.

I know at least that Shift works (menu is cycling) , Enter, up/down/left/right but pressing regular characters give me symbol letters, interesting fun :)

[dinoboards]

Sounds like you making some good progress.

You defiantly should be getting Nexor to boot though. The keyboard issue might be related - as the PPI does drive bank switching, if the switching is not fully working - the bios may not be able to switch over to the Nextor bank. That's my only guess at this stage.

So double check all your solder points and traces on the PPI and then the memory board. And continue to avoid using Compact Flash module until you get the keyboard and Nextor booting.

Good luck

[kbenayed]

I think the system is in a better place now. The sound card is detected, Keyboard appears to work and the system boots fully to the A> prompt. I traced it to one bad capacitor (May be I killed it during soldering) and got more stability after I washed the boards with Alcohol.

Keyboard is not 100 % yet, I do get proper keys now instead of random scrolling garbage. few keys are not working well which I am working through.

[dinoboards]

Sounds like you are making some excellent progress.

Good luck - keep me posted please..

Cheers Dean

[kbenayed]

Thank you.

The machine works now, boots into MSX-DOS reliably, can load programs etc. including graphic etc. I did try to fire up few games (that I really, truly own from my childhood) and to my delight, they came to live once again! That was truly insane! :)

I am still struggling a bit with the keyboard. All keys are working reliably now and no longer printing multiple characters short of "r" which is consistently printing "mr" instead. I will re-re-do all the solder points on the keyboard trying to find the culprit. I appreciate any tips on how to diagnose these type of issues if you can.

Thank you once more for your support.

Regards, Karim

[dinoboards]

The machine works now, boots into MSX-DOS reliably, can load programs etc. including graphic etc. I did try to fire up few games (that I really, truly own from my childhood) and to my delight, they came to live once again! That was truly insane! :)

Fantastic news. So glad to hear about your delight - I know the feeling. Its so cool!

... multiple characters short of "r" which is consistently printing "mr" instead

Hmm. I tried to 'reason' the logic flow in the matrix of keys and diodes that might cause your specific issue -- its a challenge. Almost certainly a short somewhere - perhaps a diode or switch etc.

First thing - as you state, check and reflow all the solder joints around the affected keys - consider the schematic (https://github.com/dinoboards/yellow-msx-series-for-rc2014/blob/main/keyboard/schematic.png)

If it the issue persists, then only advice I can give -- Disconnect keyboard. Get your multimeter out. and test, test and test again.

Have a look at the schematic and consider how the keyboard scanning happens. The various ROWx lines are typically HIGH. 'Scanning' happens by:

1. Changing one of the 9 ROWx at a time, from HIGH to LOW.
2. As each specific row goes LOW, then the 8 COLUMNx lines are read

The corresponding column for the specific key should go LOW - and only that line. M and R share the same row. There may be a short somewhere that's allowing the column for M to activate when R is pressed.

The COLUMN lines are pulled HIGH by default (R4 bus resistor). So they should all read HIGH, until a key is pressed and its ROW is currently LOW. When its ROW is LOW, then its corresponding COLUMN (and only its COLUMN) should go LOW.

What happens when M is pressed?

Now there are a lots of diodes, so you need to make sure you have your multimeter polarity such that it will flow correctly. (from positive column to negative row).

Check your measuring with some of the working keys first. Then try to zoom into the fault.

If you do see the 2 COLUMNS going LOW in response to one key - you still have the challenge to figure out why. I feel it must be a short across a diode or switch. Since its only that one key giving you grief - it implies the other rows are good. So not a logic chip issue - otherwise you would see other keys giving you issues. Well maybe - sometimes things can be really weird... So no assumptions....

Have fun!

[kbenayed]

Thanks, this will be fun. I am already grateful all other keys are working now.

m and all other keys works fine. I will keep you updated.

Best regards, Karim

[kbenayed]

Hi Dean,

The keyboard is working perfectly finally. I confess I have almost gave up few times. I could not find a physical fault with it after a second soldering pass and a lengthy verification session with a Multimeter. I cleaned it up thoroughly with Alcohol one more time and that somehow did it. Oh well. I am not complaining especially that I learned more about PPI/Keyboard logical design that I ever thought possible.

I think this build is now complete (honestly, against many odds :) especially my poor soldering skills and initially a severe lacking understanding of PPI/memory bank switching logic).

I really appreciate your patient coaching as I was working through completing this project.

I have purchased a cartridge slot extension kit to see if I can get my old MSX cartdridges to work once again. (F1 Spirit, Ping Pong, Salamander etc.) , see if my MSX disk drive still has some life in it and eventually built a wood case for the machine and the keyboard.

As a background, I grew up in Tunisia before migrating to the US. My first computer in the eighties was a Sakhr MSX1 AS-370 that I still own to this day and fire up at least once a year. I learned Basic programming on it and to some extent English (Needed to translate the programming book from English to French) , wrote few titles back then like MSX-Draw and few office tools like inventory management, invoicing and crude flyers/catalogue creation tools that my dad used to run his factory for over a decade thus this project really meant a lot to me :)

Best regards, Karim Benayed

[kbenayed]

I was never able to perfectly fix the initial keyboard. there were always 2 keys that would not work well, R and right key. I messed up with that keyboard initially and had to unsolder something, I may have damaged the board somehow, no matter for now, the new keyboard and controller are working perfectly.

I have a display question though. Although initially Dos and Games are working perfectly, when on dos mode, the text returned from command like dir are garbled a bit. I have to go to basic, issue screen 2 for example , call system then dir "a:" would return correct text. I am curious if you have seen that.

Thank you.

[kbenayed]

Hi, a correction, I noticed that the text gets corrupted in msx-dos only when the text reaches the end of the screen and scrolling starts. once the lines start to scroll up then the display gets corrupted. I appreciate any hints if you can think of any.

Thank you.

[dinoboards]

Hi Mate,

sorry for the late reply.

Your current issue sounds a bit odd.

Nothing immediately comes to mind as to cause.

Typically when i have an issue like this, its usually related to software - the code is driving the VDP too fast - causing corruptions. I doubt this is your issue though

Have you tried running any other graphics programs?

Try to minimise the build configuration - eg: remove the Music and Sio/2 module - and any other optional modules.

Also, if possible, try with a new ROM image downloaded from this repo's releases.

Dean

[kbenayed]

absolutely no worries, after some fiddling, I decided to check the clock speed which was actually the culprit, I accidentally had set it to 3.6. setting it back to 2.45 solved the issue. I somehow completely missed that.

Thank you again for your support. The build is now complete, I will share some pictures soon.

Regards, Karim

[dinoboards]

Good to hear its working - but it should work find at the 3.6Mhz setting - in fact for the CBIOS ROM image, I had patched the code to enable operating the VDP with the CPU running at 7Mhz.

Its possible something regressed in my software. I will need to reconfigure my rig and reproduce your setup and see if I can reproduce.

Typically the MSX operate at around the 3.5/3.6Mhz range - so everything should and needs to work at that frequency.

Cheers Dean

[kbenayed]

You are correct. I confused the standard speed somehow in my mind. As most games are working perfectly (F1 spirit, Metal Gear 2, Aleste, Zenex). It may be reasonable to think it could be a software issue, I ordered the Turbo CPU kit for now. I will deploy the MSX Build kit and play with that side as well.

Regards, Karim

[kbenayed]

I managed to build the kernel locally. the yellow-msx-ntsc/pal-rc2-14.rom was produced and is working well.

The Country-with/without-rtc generates a -main.rom , -opt.rom and -subrom.rom. it does not generate a file with just ...rtc.rom.

Did I miss a step somehow ? I apologize if this is a silly question and that I missed a documentation section.

Regards, Karim

[dinoboards]

Hi Karim

No need to apologise.

Not sure what process you have followed - as that is a file name that doesn't seem right to me. Did you use the docker wrapper command/process - or try to build directly?

Unless you want to modify the code or change configuration, you can download pre-built images. There a lots of images available in the Release section of this repo.

In particular: https://github.com/dinoboards/yellow-msx-series-for-rc2014/releases/tag/24-09-08

Download the msx-rc2014-24-09-08.zip - there you will find various builds for different countries with/without RTC support.

Dean

[kbenayed]

i take it all back. I was looking at files like: usa-with-rtc-main.rom and missed the fact that I needed to look at: msxsyssrc-rc2014-usa-with-rtc.rom type files. I apologize. Docker is building just fine

[kbenayed]

It seems the new build does not have the scrolling text corruption. My testing was interrupted unfortunately as the repeated removal and putting back of the ROM IC damaged the IC socket pins. Tried to unsolder it and solder a new one the board became instable. I ordered a new one for now while troubleshooting with direct wirings

[kbenayed]

Hey, I fixed the card! I managed to trace the wires and zero on the culprit! I am no longer having scroll issues or boot problems. I cannot believe I managed to fix it after what I had it go through!. I know I order the additional card which is fine I guess, it may not be stable in the long run. I am very happy at the moment :)

[dinoboards]

That's great news. Well done. It's always possible!

I have yet to send your new kit. I am not sure if I can manage refund in tindie. Happy to try if U want. Otherwise I will parcel it up tonight my time

On Wed, Nov 6, 2024, 9:28 AM kbenayed @.***> wrote:

Hey, I fixed the card! I managed to trace the wires and zero on the culprit! I am no longer having scroll issues or boot problems. I cannot believe I managed to fix it after what I had it go through!. I know I order the additional card which is fine I guess, it may not be stable in the long run. I am very happy at the moment :)

— Reply to this email directly, view it on GitHub https://github.com/dinoboards/yellow-msx-series-for-rc2014/issues/16#issuecomment-2458266533, or unsubscribe https://github.com/notifications/unsubscribe-auth/BDRG3PSIZXTTDSQPXSYCP4TZ7FA7HAVCNFSM6AAAAABOXAS5BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJYGI3DMNJTGM . You are receiving this because you commented.Message ID: @.***>

[kbenayed]

Thank you for the option, I appreciate shipping it still. You never know especially that I am still experimenting with Rom code and all at the moment. It is always good knowing I have a backup as I am very active on this system. Really thank you for designing it and building it. It is an amazing learning experiment.

Regards, Karim

[kbenayed]

Hi,

I confirm that while using the Turbo CPU board Turbo: 7.3 Clock1: 3.6 Clock2: 0.3

and Turbo switch set to:

Position 1 (lower to ground) : MSX-DOS/Basic, no text corruption Position 2: (Middle) MSX-DOS/Basic, no corruption. Position 3: (Top from ground) MSX-DOS/Basic: Same corruption I see with RC2014 Stock CPU and Clock at 3.5

I hope that help. I have a fully functional system now and the Rom Board is fully stable. Thank you again so much! I am up to try enabling networking now.

Best regards, Karim

[zomgugoff]

I also had the text corruption issues (as well as the compatibility issues). I ended up replacing the main oscillator on Turbo board with a 7.15909MHz crystal. That fixed all of the corruption and most of the compatibility issues I had. There is a proper clock signal coming out of pin 8 of the V9958 that can be wired to the upper leg of the 47ohm resistor(R5) to give the CPU, as long as you remove the original 7.3728MHz oscillator. That will interfere with overclocking, though. Replacing it with the slightly slower one will still allow overclocking to work.

Here are the ones I ordered: https://www.aliexpress.com/item/3256804928269823.html?spm=a2g0o.order_list.order_list_main.23.21ef1802YcVzSA

[vipoo]

Sorry to hear of the issues.

There should be no video corruption during scrolling of the standard 80 column or 40 column text screen modes, at any cpu frequency, using the msxdos or cbios rom images.

It's not something I have observed on my test rigs. I have tested with various VDPs .

Very strange. Something odd happening here. I need to investigate this a bit more to see if I can reproduce

Dean

On Sun, Nov 10, 2024, 5:30 PM zomgugoff @.***> wrote:

I also had the text corruption issues (as well as the compatibility issues). I ended up replacing the main oscillator on Turbo board with a 7.15909MHz crystal. That fixed all of the corruption and most of the compatibility issues I had. There is a proper clock signal coming out of pin 9 of the V9958 that can be wired to the upper leg of the 47ohm resistor(R5) to give the CPU, as long as you remove the original 7.3728MHz oscillator. That will interfere with overclocking, though. Replacing it with the slightly slower one will still allow overclocking to work.

Here are the ones I ordered;

https://www.aliexpress.com/item/3256804928269823.html?spm=a2g0o.order_list.order_list_main.23.21ef1802YcVzSA

— Reply to this email directly, view it on GitHub https://github.com/dinoboards/yellow-msx-series-for-rc2014/issues/16#issuecomment-2466608161, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADIL7VCLIEUI5EZ7GZBVBTZ734R7AVCNFSM6AAAAABOXAS5BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRWGYYDQMJWGE . You are receiving this because you are subscribed to this thread.Message ID: @.*** com>

[dinoboards]

Ok - done some testing

I had completely forgotten about the need to ensure that the 1 CPU Wait State is enabled for MSX software. This is enabled via the PPI module (short the jumper). The Turbo CPU will generate the required wait state as needed, so the jumper on the PPI is not needed for the PPI module when using the Turbo CPU.

RC2014 stock CPU with Stock Clock Module

1. Tested with Clock @7.3728Mhz and @3.6864Mhz
2. Ensure the Jumper is shorted on the PPI module (this generates the required CPU Wait State)*
3. The CBIOS image (NTSC) scroll just fine in text 80 mode just fine
4. Corruption will happen if the wait state is not enabled.
5. The MSX-DOS image only works at the 3.6864Mhz Freq
6. without the wait state enabled - scroll corruption will be observed.
7. On boot up - the boot text should indicate the correct speed of the CPU, with M1 stated if the wait state is being generated. eg: CPU: 3.5Mhz (M1)

* The PPI must have the wait state jumper enabled, or corruption may happen and some programs may have compatibility issues.

Turbo CPU (20Mhz Turbo Clock and 7.3728Mhz secondary crystal

1. Clk 1 shorted for 3.6864Mhz (2nd junction one from top)
2. Slow clock jumper shorted J1
3. Turbo shorted to fast (top junction)
4. Boot up reports 3.5Mhz (M1) if slider at top
5. Boot up reports 20Mhz (M3) if slider in middle
6. Boot up reports 20Mhz (M1) if slider at bottom
7. No text corruption observed during scrolling for both MSX-DOS and CBIOS rom images.

I tested with ROM images from release 24-09-08

I don't recommend enabling the M1 junction on the PPI when using the Turbo CPU. I did not observe corruptions when doing this, but it does 'conflict' a bit with the calculations for CPU frequency.

Can you please advise what revision of the Turbo CPU you have - in case there is some regression specific to a particular revision.

Dean

[zomgugoff]

I'm assuming this wasn't aimed at me, but I got to looking at my PPI board because I was confused about the wait state jumper you mentioned. I apparently installed a disc capacitor in J2 when I built the card! I haven't had any issues since replacing the crystal, but I guess I need to put a pin header in J2.

[kbenayed]

I don't have the M1 or one wait state when booting in 3.5 mode. Screenshots are attached. I get M1 and M3 at 20MHZ as expected.

Here is what I noticed:

When I boot in 40 width mode, I have corruption, When I mode 80, corruption is gone When I mode 40, corruption is still gone consistently, I was not expecting that actually. something about switching from 40 to 80 apparently. in my case.

[kbenayed]

Hi zomgugoff,

Thank you, I will keep that in mind.

I also had the text corruption issues (as well as the compatibility issues). I ended up replacing the main oscillator on Turbo board with a 7.15909MHz crystal. That fixed all of the corruption and most of the compatibility issues I had. There is a proper clock signal coming out of pin 8 of the V9958 that can be wired to the upper leg of the 47ohm resistor(R5) to give the CPU, as long as you remove the original 7.3728MHz oscillator. That will interfere with overclocking, though. Replacing it with the slightly slower one will still allow overclocking to work.

Here are the ones I ordered: https://www.aliexpress.com/item/3256804928269823.html?spm=a2g0o.order_list.order_list_main.23.21ef1802YcVzSA

[dinoboards]

@kbenayed - thanks for the images.

I do not know how, but your boot up image showing a CPU speed with no M1 wait state is not what should be seen.

In all configurations, we need the M1 wait state enabled. There are 2 ways to enable this wait state:

1. By shorting the jumper on the PPI module (which from your image I can see is applied)
2. By using the Turbo CPU, which includes the wait state generator on board.

Its not recommended to have both generators enabled - so I recommend you remove the jumper from the PPI module.

I did test with the jumper shorted and using the Turbo CPU - and I still see on my rig, the M1 wait state reported on boot up. So I am very confused as to how your system reports no wait state at all.

Maybe try a few things for me:

1. Using the Turbo CPU, and removing the jumper from the PPI - boot up with the turbo's slider in each of the position - and note done what CPU frequency and wait states are reported - you should see: { 3.5Mhz (M1), 20Mhz (M3) and 20Mhz (M1) }
2. If you still have your stock RC2014 CPU and clock module, swap the Turbo CPU for those and re-insert the jumper into the PPI module - and note its reported CPU speed on boot.

Dean

[kbenayed]

I tested all requested used cased, I still have no M1. I tried the older PPI card I had (the older keyboard that had few issues) and the M1 is there! I swear I have soldered the new card really well, I will troubleshoot it later. at the moment with this setup , I have no corruption at all!!!

So the issue was the new PPI card all along somehow. I will try to troubleshooted more tonight an confirm.

Thank you for the information that the PPI J2 setting is the key issue here. I will get to the bottom of it.

Regards, Karim

[dinoboards]

Ok. So that's is interesting. I need to think about this and review my schematics

It seems like that maybe the wait state is being held/forced high all the time

But there is still something not quite adding up to me here.

A bit to walkthrough. I am afk at the moment. When I get a chance I will send some more analysis of what I think might be going on here.

Dean

On Tue, Nov 12, 2024, 6:51 AM kbenayed @.***> wrote:

I tested all requested used cased, I still have no M1. I tried the older PPI card I had (the older keyboard that had few issues) and the M1 is there! I swear I have soldered the new card really well, I will troubleshoot it later. at the moment with this setup , I have no corruption at all!!!

So the issue was the new PPI card all along somehow. I will try to troubleshooted more tonight an confirm.

Thank you for the information that the PPI J2 setting is the key issue here. I will get to the bottom of it.

Regards, Karim

— Reply to this email directly, view it on GitHub https://github.com/dinoboards/yellow-msx-series-for-rc2014/issues/16#issuecomment-2468916531, or unsubscribe https://github.com/notifications/unsubscribe-auth/BDRG3PXE3OVSS5AVQI2R75L2AEDEJAVCNFSM6AAAAABOXAS5BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRYHEYTMNJTGE . You are receiving this because you commented.Message ID: @.***>