What's new
Also, how is this related to the following stuff?
its not related, Naomi 2 have JP9-13 jumpers, which selects what will be routed to CN8 - RS232(SH4 SCIF) or RS422(MIE MCU), but Naomi 1 does not.

also, I don't think there exists any Naomi 1 jumpers functions explanation, which may be trusted.
 
sorry I wasn't clear. I did note that you were working on a N1 vs N2, I guess what I meant to ask is, is the "SH4 SCIF" output that would go down CN8 in this case, the same as what you would expect on the pins that you are tapping now off the pins of the cart connectors?

Also noted re: the available jumper explanations!
 
Last edited:
Well done sir, care to share the pins you tapped? eventually ?

I hope you got some fun output on that UART! I'm guessing all sort of debug messages galore. =]
Probably not; reasoning being that there is no standard application to use it for. Was running custom application/code on N1 to accept commands from PC to control SH4/G1BUS while watching with logic analyzer. Similar deal to how I was able to solve cart algorithm used by the Atomiswave.
 
Well done sir, care to share the pins you tapped? eventually ?

I hope you got some fun output on that UART! I'm guessing all sort of debug messages galore. =]
Probably not; reasoning being that there is no standard application to use it for. Was running custom application/code on N1 to accept commands from PC to control SH4/G1BUS while watching with logic analyzer. Similar deal to how I was able to solve cart algorithm used by the Atomiswave.
Looking through several of the games seems to imply they do indeed have some sort of debug output, the question is where is the intended destination of the printed messages? I would expect this UART you are poking at, wouldn't you?

Here are some examples games that you may test out if you have time.

$ strings AtomisWave/AW-MetalSlug6.bin | grep SCIF
Startup SCIF 115200 BPS Buffer[%dByte]

All these files have the same "Startup SCIF" string as Metal Slug
Binary file AtomisWave/AW-ViolentMetalSlug6.bin matches
Binary file AtomisWave/MetalSlug6.bin matches
Binary file AtomisWave/NeoGeoBattleColliseum.bin matches
Binary file AtomisWave/basschanllenge.bin matches
Binary file AtomisWave/gdrom_KOFXI.bin matches
Binary file AtomisWave/gdrom_KOFXI_controles_JVS_OK_Video_OK_v4.bin matches
Binary file AtomisWave/gdrom_KOFXI_v5.bin matches
Binary file AtomisWave/gdrom_KOFXI_v5_AllFighters.bin matches
Binary file AtomisWave/kofxiallfighters.bin matches
...
Binary file Naomi1/MeltyBloodActCadenza(RevA).bin matches
Binary file Naomi1/MeltyBloodActCadenzaVerB2_v3.bin matches
Binary file Naomi1/MeltyBloodActCadenzaVerB_v3.bin matches
Binary file Naomi1/MeltyBloodActressAgain.bin matches
Binary file Naomi1/MeltyBloodActressAgain_v6.bin matches
Binary file Naomi1/ShikigamiNoShiroII_v6.bin matches
Binary file Naomi1/TetrisKiwamemichi_v6.bin matches
...

I suppose I can just Saleae the output pins myself, it would be easier if you'd just share what you already know about the pinout of course.

I recall Dknute sharing once that he had found a log on his Harddrive from an emulator logging said output:

" I just found this serial port log sitting on my hard drive. Try to guess which game it came from (don't let the text fool you, it's from NAOMI):" https://dknute.livejournal.com/31480.html

Nindows2 for DREAMCAST version 2.12(C)
SEGA ENTERPRISES SYSTEM R&D Library Team
Startup SCIF 115200 BPS Buffer[1024Byte]

HEAP INITIALIZE Address = $8dc16140
Size = $00027c00I know

"Nindows" (and Gindows) is a Sega debugger that can be enabled in various games. https://assemblergames.com/threads/where-does-the-gindows-debug-library-come-from.66906/"Gindows and Nindows, as the name implies, are very Windows looking debug user interfaces for use in Dreamcast games.

Where does Gindows actually come from? I've only seen it in Rez so far. Nindows however has popped up in a few places like Sonic Shuffle, beta 836 of Rez, and multiple sdk samples and tech demos (Tower of Babylon, for example)"
 
Last edited:
the question is where is the intended destination of the printed messages? I would expect this UART you are poking at, wouldn't you?
game -> development ROM board (with SCSI and UART) -> dev. PC -> debugger / monitor software
normally there used SCSI during development, however as you noticed some games contain SCIF comm texts, I'd guess leftover of some SDK library functions.

"Nindows" (and Gindows) is a Sega debugger that can be enabled in various games.
no, its not.
Nindows is GUI library from Katana SDK, which may be used to whatever purposes.
why not RTFM a bit ? Katana SDK/PDFs/Ninja_GD.pdf :
1 Summary
Nindows is an easy to use GUI system for performing tasks essential to game development such as debugging and adjusting parameters on the actual machine and the host machine.

so, it is mainly library for typical UI things - windows, buttons, etc etc
not top secret debugger lol
Where does Gindows actually come from? I've only seen it in Rez so far.
Gindows seems custom GUI / API developed by Rez authors.
 
Thanks for the updated detail... looks like I left some " marks off those statements but they were sourced from others in the community, those Nindows / Gindows assertions were not mine. I'll take a peak at Ninja_GD.pdf later.

"I'd guess leftover of some SDK library functions"
so you don't think they are in use? or if they are it was not intentional.

I'm wondering if you tap the pins that you have mapped, and launch the game shown in dknutes blog IF you will see the same output that the emulator captured.
 
so you don't think they are in use? or if they are it was not intentional.
I'd guess they was in use during game development, when game was running on development Naomi board / unit, which had usual DB9 serial port connector, and may be easily connected to PC terminal.
so, all its not really interesting or important if we talking about retail NAOMI 1 mobos, which have no RS232 wired to filter board connectors.

and again, why you are interested ?
I know why and what for it needed for brizzo, but wondering about causes of your interest.
 
so, all its not really interesting or important if we talking about retail NAOMI 1 mobos, which have no RS232 wired to filter board connectors.

and again, why you are interested ?
I know why and what for it needed for brizzo, but wondering about causes of your interest.
Even if it isn't wired to the filter board, are the signals still tappable on the motherboard if one were so inclined?

As fas as interest... I enjoy seeing how things talk. My Saleae is bored =] https://www.saleae.com

I often equally wonder to myself "why share teasers like this, if one has to have a magical key (reason) to get further detail?".
Sure we can get a pretty good idea of which pins are tapped from this photo, but why not just come out and say:
"I wound up finding the pins for the UART on x and y, in case anyone cares", and leave people to their own devices. It was kind of weird for me to ask if the pins would be shared and basically get an "I don't think so". Lol what is the point?

Likewise it is equally puzzling to me as to why I get razzed a bit for "sharing things / statements / not asking a question" (paraphrasing other posts), etc. , yet folks in this post are supposed to magically appreciate and derive what "Please tell me your secrets. Where is your UART port?" is all about.

I assume this is all of course some sort of general interest teaser for a potential future Naomi Cart. I'm just generally following / playing along. I don't find the need for a purpose as many of you do generally speaking.

index.php

Oh well "I don't know what's happening, but I like it!" seemed to cover it! Thanks for the teaser none the less!
 
This conversation reminds me of the people who complain about Demul not being open source, but can't explain why it needs to be open source or how they plan to contribute

The in-game debug menus most of these games have are far, far, far more interesting than the small tidbits some output on uart (it's literally useless information imo)
 
I wanted to use demul once to replace original gaelco hardware on an ATV track.
If I would have had the sources, I would have tried to improve communication between 2 systems.

The original hardware keeps freezing and resetting after a while. Last fix was reflashing the unit.

It's now stable again, I just don't know for how long.

The emulator sources are also helpfull to understand how the real hardware works.
Many people study mame code to understand hardware. You even can simulate hardware faults by altering the emulator code and
you can see if it behaves like the real (bad) behaving hardware.

So, emulator sources are usefull.
 
This conversation reminds me of the people who complain about Demul not being open source, but can't explain why it needs to be open source or how they plan to contribute

The in-game debug menus most of these games have are far, far, far more interesting than the small tidbits some output on uart (it's literally useless information imo)
please don't get it twisted I'm not complaining (in that regard, as I said I have my own Saleae, what you did isn't magical. Why you choose to hold on to it so tightly is beyond me).

Maybe I should flip this around on you and just ask "what was your intent in sharing the photo, and letter to your Naomi" as you did?

Because it kinda reminds me of those people that buy those really loud exhausts for their car, and just drive around your neighborhood. Just because they can. HEY LOOK AT ME! ;)
https://www.amazon.com/Muffler-Exhaust-Whistle-Prank-Joker/dp/B005OKM0PE

Not at all surprised by your answer btw, rather than simply making further conversation, best to double down on asking "WHY do you want that"?
 

Attachments

  • 41E6oDCVeNL.jpg
    41E6oDCVeNL.jpg
    28.6 KB · Views: 58
I wanted to use demul once to replace original gaelco hardware on an ATV track.
If I would have had the sources, I would have tried to improve communication between 2 systems.

The original hardware keeps freezing and resetting after a while. Last fix was reflashing the unit.

It's now stable again, I just don't know for how long.

The emulator sources are also helpfull to understand how the real hardware works.
Many people study mame code to understand hardware. You even can simulate hardware faults by altering the emulator code and
you can see if it behaves like the real (bad) behaving hardware.

So, emulator sources are usefull.
I think it will be better if you start new topic about ATV track.

this game uses NAND flash ROMs, which is dying slowly within time by design, and it looks like yours not in good condition.
ATV have smart enough design - at boot game does self-test and if it spot some problems with NAND it does full flash ROM reprogram. however, this will not help if there happen unrecoverable errors.

sources - you may look at MAME, there is working code. it shows nothing onscreen but game code is running as it should, at least it was like that last time I checked it.
but emulation will not help to reproduce your issues - NAND "aging" is not simulated :)
 
Last edited:
Ok guys, now that the Arcade Godz have favored us and it appears that a CPS1 multi is in the works :thumbsup: Its time to doule up the efforts in showing support/interest for a Naomi multi cart and finally ditch them nasty netdimm and crazy psu requirements.
 
Back
Top