#Atari Jaguar

1 messages · Page 5 of 1

rotund portal
#

A bit confusing, with the address bus from Tom, and the bus from fx68k.

thorny swift
#
  1. It’s the Area 51. All docs say that’s Motorola
rotund portal
#

0x80000 is technically the Cart ROM location, but I loaded the Area 51 ROM as a "BIOS" at 0xE0000 first.

thorny swift
#

Maximum force is the R3000

#

Maybe vicious circle too but that would be a BIT more expensive haha

rotund portal
#

So in theory, the core reads the SSP and PC from 0xE00000, then jumps to the 0x80000 range, and finds the correct code there.

thorny swift
#

I’m not too worried. If they accept the offer I’ll make a vid on it. Maybe two. Revenue from that, cleaning it and converting it to solid state and being sold from a “known good seller”…I’ll at minimum break even. Probably just friends and family price sell it to someone I like

rotund portal
#

Yeah. A vid would be interesting, for sure.

#

oic - the addr bus from the 68K is missing the LSB bit, because it does anyway...

#

Since the instructions are generally read as 16-bit wide (on the 68000), they ditched the LSB bit of the Address.

#

And just use the UDS_N and LDS_N strobes to select each byte.

#

(well, usually during writes)

warm oasis
#

Did you ever dig into Jag CD, Ash?

rotund portal
#

So that address on "eab" starting from 0x40E583 on SignalTap, is really our jump address of 0x81CB06.

rotund portal
# warm oasis Did you ever dig into Jag CD, Ash?

I had a brief look at it a few years back, when Kitrinx and I last looked at the Jag core.

But since the core wasn't running too well back then, it didn't seem worth looking into the CD stuff further.

#

The CD drive is based on a Philips mech, IIRC.

thorny swift
rotund portal
#

But they also have a small custom ASIC, to talk to the cart slot etc.

#

I already bought a Marantz DVD player a few weeks ago, as part of an effort to make a "new" GD drive for the Dreamcast.

#

And that's been sat on the bench for weeks now. lol

#

So I learned a ton more about CD/DVD drives recently, which could come in handy for Jag later.

#

To be completely honest, though, it was stressful enough getting the PCE CD thing to boot a game for the first time. lol

#

I was working with dentnz on that during a "heatwave" a few years back.

#

We worked every night for a long time on it, until we finally got Rondo of Blood to boot.

thorny swift
rotund portal
#

Finishing the rest of the core turned out to be even harder, but Srg320 wrote his own thing in the end.

#

(at least I think it was Sergey, who wrote the eventually CD part of the PCE core?)

#

Sorry, I know my thoughts and typing are a bit sporadic. It's 2:25am here now.

#

And my brain has been on the Jag core most of the night.

warm oasis
#

Where you based Ash?

rotund portal
#

"Mordor", South West UK.

#

That's better. I stole the oReset signal (which stays low as the core is running), to use as the LSB bit of the 68K EAB (address) bus.

#

Now it shows the correct jump address.

#

No other activity though. Nothing on-screen, but...

#

Cojag has I think 6MB of RAM on most versions of the board.

#

So now I need to look at whether the Jag core is limiting the amount of accessible RAM.

thorny swift
rotund portal
# 
wire [19:0] dram_addr = {ras_latch, dram_a};//abus_out[22:3];//{ras_latch, dram_a};
#

Booo! ^

warm oasis
#

I did as well. I am up in Edinburgh, where it is now very cold.

rotund portal
#

I have Scottish roots.

#

Well, a mildly ginger beard.

#

My Granddad's parents were born in Inverness.

warm oasis
#

Hah, mine goes a bit ginger as well, especially in the summer months

#

Something worth considering, if adding co Jag support is viable may be worth getting lightguns and virtual lightguns working for the balloons homebrew if it is going to be the same style controlls for co Jag as well (I am assuming it is the same implementation, but I am no expert on this stuff)

rotund portal
#

I can't figure out how much memory the core can access atm, but probably quite a lot...

warm oasis
#

These Co Jag games are all lightgun games, right?

rotund portal
#

GreyRogue modified the SDRAM controller(s), so it uses the DRAM address more directly.

#

(which makes it work a bit closer to the original.)

#

So it latches the Row address to Activate, erm, a row.

#

Then latches the Column address for the actual read/write burst.

rotund portal
thorny swift
#

Released games are all lightgun games

#

Vicious circle is fighting. Fishing frenzy is who knows? I’ve never played it

rotund portal
thorny swift
#

So vicious circle would need the input signals off JAMMA

rotund portal
#

Looks like Area 51 does a basic memtest at start-up.

#

Or more like, memory detection.

thorny swift
#

I wonder if it also is sensitive to it being the right amount. As in secondary security checks against memory allocations. Even HDD size can be set as a secondary check in arcade boards

#

I’ve seen ram amounts / HDD size / CF size being flagged to try and prevent bootlegging.

serene widget
rotund portal
#

Ooh.

# 
    map(0xb70000, 0xb70003).rw(FUNC(jaguar_state::misc_control_r), FUNC(jaguar_state::misc_control_w));
serene widget
#

This is the full list of CoJag games?

rotund portal
#

Code is trying to access 0xB70002

warm oasis
# serene widget This is the full list of CoJag games?

Only 2 games (and their combo) were officially released:

Area 51
Maximum Force
Area 51/Maximum Force Duo (combines both games in a single cabinet)
4 unreleased prototypes exist:

Fishin' Frenzy
Freeze
Vicious Circle
3 on 3 Basketball

dusk slate
#

😵‍💫

rotund portal
# 
void jaguar_state::misc_control_w(offs_t offset, uint32_t data, uint32_t mem_mask)
{
    logerror("%s:misc_control_w(%02X)\n", machine().describe_context(), data);

    /*  D7    = board reset (low)
        D6    = audio must & reset (high)
        D5    = volume control data (invert on write)
        D4    = volume control clock
        D3-D1 = audio bank 2-0
        D0    = shared memory select (0=XBUS) */
warm oasis
#

It would be good if any keen bean who uses Mame is able to do some digging and see if all 4 of those prototypes are out there in the wild and if they are playable, and what type of controls they use. Even Awbacon has only played one of them

thorny swift
warm oasis
#

They definitely not in the wild and not supported by Mame?

thorny swift
#

I’ll ask someone from MAME who knows all

warm oasis
#

Nice, be good to know if this is even a possibility

thorny swift
#

But if I have never seen them odds are it’s either just documented evidence of them existing or “in private collections”

warm oasis
#

Yeah, that is the fear

#

So is Fishing Frenzy not really playable? What is the deal with that one?

thorny swift
#

Yeah it’s easy to find

#

Got answer back. All but 3 on 3 exist

rotund portal
#

It tried to write to the MEMCON regs on Tom, before it seems to crash.

image.png
#

But hey, at least it's running some code. lol

thorny swift
#

So the released games plus Freeze / Vicious Circle / fishin frenzy can be located

warm oasis
#

Incoming Awbacon video covering the entire Co Jag library? 😉

thorny swift
#

Because that’s 90% hardware

#

Getting that 3DO M2 demo disc done was about as much as I’ve ever coded and still I couldn’t figure out how to loop back from the last asset loaded in to the beginning so my directions were “just reset and start again” 🤣

rotund portal
#

Looks like that address is near the top of memory on Cojag.

#

But it ofc doesn't exist in the Jag core (yet), so the 68K doesn't receive DTACK for that range.

thorny swift
rotund portal
# 
// Latching of memory configuration register on startup
// This XMA pins are pulled High or Low by resistors on the Jag board.
assign xma_in[0]  = (xma_oe[0])  ? xma_out[0]  : 1'b1; // ROMHI
assign xma_in[1]  = (xma_oe[1])  ? xma_out[1]  : 1'b0; // ROMWID0
assign xma_in[2]  = (xma_oe[2])  ? xma_out[2]  : 1'b0; // ROMWID1
assign xma_in[3]  = (xma_oe[3])  ? xma_out[3]  : 1'b0; // ?
assign xma_in[4]  = (xma_oe[4])  ? xma_out[4]  : 1'b0; // NOCPU (?)
assign xma_in[5]  = (xma_oe[5])  ? xma_out[5]  : 1'b0; // CPU32
assign xma_in[6]  = (xma_oe[6])  ? xma_out[6]  : 1'b1; // BIGEND
assign xma_in[7]  = (xma_oe[7])  ? xma_out[7]  : 1'b0; // EXTCLK
assign xma_in[8]  = (xma_oe[8])  ? xma_out[8]  : 1'b1; // 68K (?)
assign xma_in[9]  = (xma_oe[9])  ? xma_out[9]  : 1'b0;
assign xma_in[10] = (xma_oe[10]) ? xma_out[10] : 1'b0;
#

Looks like Cojag (68K) uses the ROMHI config, which is the same as the Jag.

#

But CoJag probably maps the ROM to both the 0x800000 and 0xE00000 ranges?

#

(a few words mapped to 0xE00000, or maybe the whole ROM. Then it almost immediately jumps to an offset in 0x800000 anyway.)

#

It does do a couple of Writes to the MEMCON regs, at least.

#

But then goes haywire.

#

Such a weird place to jump to.

#

OK, could be 68020 stuffs.

# 
81CB6A: 6400 FFF2                                              bcc     $81cb5e
81CB6E: 33FC 1F00 FFF0 00E0                                    move.w  #$1f00, $fff000e0.l
81CB76: 33FC 0000 FFF0 00E2                                    move.w  #$0, $fff000e2.l
#

Dunno.

#

Gonna sleep soon. zzzzzzz

ashen spoke
#

lol I’m playing Jaguar

#

What a time to be alive

#

I’m collecting power balls in a giant house

#

What a time to be alive

thorny swift
#

@ashen spoke someone just DMd me a photo of your truck

FB_IMG_1731987708843.jpg
ashen spoke
thorny swift
ashen spoke
#

LOL

dusk slate
ashen spoke
#

Arrrgh how do I get the Cybermorph lady to say “where did you learn to fly”

dusk slate
#

How the heck can they even see out of the rear view mirror though!?

ashen spoke
#

Yeah that’s crazy

#

Like whatever makes people happy but sometimes you gotta keep your hobbies a secret LOL

thorny swift
dusk slate
thorny swift
#

Cheese pun for the win

dusk slate
serene widget
#

Mmm...

Sharp cheddar...

thorny swift
#

No Wisconsin garbage. Velveeta grade state

mild karma
warm oasis
#

OK, anyone who magically had the Jaguar BIOS from running Update All (i.e. was using the WIP DB) you will get the Mister Kun Jag BIOS next time you run it.

rotund portal
#

Awake again. Another new day.

#

Fairly sure the Cojag thing was crashing because it is using 020-specific instructions quite early-on.

# 
81CB6A: 6400 FFF2                                              bcc     $81cb5e
81CB6E: 33FC 1F00 FFF0 00E0                                    move.w  #$1f00, $fff000e0.l
81CB76: 33FC 0000 FFF0 00E2                                    move.w  #$0, $fff000e2.l
#

It seems to get to about 0x81CB6C before it crashes, which is in the middle of a longer instruction.

#

So the 020 is likely using 32-bit addressing there.

#

Where the 680000 would use 24-bit.

#

So fx68k is reading say the first three words from 0x81CB6E or whatever, then interpreting the next word (0x00E0) as an "instruction", which is obviously wrong.

#

I might try using TG68K in 020 mode, but I'm not sure it's worth the effort.

#

When it's taking 17+ minutes for each compile, and each tiny code change, it's a real killer.

#

I must have done about 20 compiles already of the past few days.

#

And I can't use TG68K in the sim, because it's written in VHDL.

#

I just added the TG68K stuff to the Jag core. I don't really know why.

sudden palm
warm oasis
#

Is this you adding in all the missing Co-jag parts?

rotund portal
#

But it looks like it pretty much adds extra RAM (6MB), and the VIA chip for handling the IDE port, etc.

#

I can only really go by the notes in MAME, and spotting things on photos of the Cojag board.

#

Currently trying to get TG68K running, in place of fx68k.

#

I have a strong feeling it won't be that easy.

#

But it would be funny to see if it can boot the Jag BIOS first.

#

Fallen at the first hurdle...

#

TG68K doesn't appear to support DMA / bus control.

#

So probably done in other logic in Minimig etc?

#

I think it's something like...

# 
    //.BR( fx68k_br_n ),        // input
    //.BG( tg68k_bg_n ),        // output
    //.BGACK( fx68k_bgack_n ),// input
#

External thingy asserts BR (Bus Request).

#

CPU asserts BG (Bus Grant).

#

External thingy asserts BGACK (Bus Grant Acknowledge), to let the CPU know it now has control of the bus.

#

So it's not super complex to implement, but a bit painful that TG68K doesn't have the logic already.

#

The Jag does use that stuff quite a lot, to allow the 68K to talk to the Tom and Jerry chips, or allow Tom to take over, etc.

#

I think Tom also supports DMA, where it takes control of the main Address and data busses.

#

For now, I just want to see if I can get the basics running, to see if TG68K runs any code at all.

thorny swift
#

lol bad new. I woke up and I own a CoJag 🤣

rotund portal
#

Oh dayum. lol

#

I'm both happy and sad for you. lol

#

(one of my fav movies, btw)

#

Real Genius - it involves Val Kilmer at his comedy peak, and big lasers.

#

Verilog / VHDL coding pet hates...

# 
    .AS( tg68k_as_n ),        // output
    .UDS( tg68k_uds_n ),        // output
    .LDS( tg68k_lds_n ),        // output
    .RW( tg68k_rw_n ),        // output
    .DTACK( fx68k_dtack_n ),// input
#

When devs don't label their signals as Active-Low, so you have to guess, or trawl through their code to figure it out.

#

All of the signal labels on the left are on the TG68K module.

#

Usually on the 680x0, those are Active-Low signals.

#

(all active-low signals on the Jag core itself, add "l" to the signal names, to denote active-Low.

#

Or elsewhere in the core, _n.

#

Not yet. lol

thorny swift
warm oasis
#

Nice one!

rotund portal
#

Now I see why Cojag doesn't map a ROM at 0xE00000...

# 
    map(0xe00030, 0xe0003f).rw(m_ide, FUNC(vt83c461_device::config_r), FUNC(vt83c461_device::config_w));
    map(0xe001f0, 0xe001f7).rw(m_ide, FUNC(vt83c461_device::cs0_r), FUNC(vt83c461_device::cs0_w));
    map(0xe003f0, 0xe003f7).rw(m_ide, FUNC(vt83c461_device::cs1_r), FUNC(vt83c461_device::cs1_w));
#

'cos the IDE chip is there.

#

It probably mirrors some of the ROM bytes to 0xE00000 to 0xE0002F or something, so it can jump to the correct ROM mirror at 0x800000.

#

(which is kind of fairly common with 68K setups in the past.)

#

VIA chip next to the IDE port.

#

I've yet to see a photo of the Dual Board without the riser plugged in.

#

The 68020 is the small chip on the right-hand side of the riser.

thorny swift
rotund portal
#

Thanks.

#

There is a small 2K EPROM on the riser.

#

Which is probably just the JAGWAVE.ROM

#

Since they include that in many of the MAME ROM zips.

#

Oh.

# 
AT28C16 16K (2K x 8)
#

That chip is only 2KBytes.

#

jagwave.rom is definitely 4KB of data. hmm

#

It's possible that 2K ROM is just a copy of the first 2K of the main ROMs? Dunno.

#

Oops, that chip IS 16K.

#

A confusing way to list it.

#

No, it's 2KB.

#

16K BITs.

#

I didn't realize the area51 "t" version was Time Warner.

#

area51a is the Atari licensed version.

uncut atlas
#

cojag has more ram, uses the second bank pin, the pull ups are different, and it uses 68020 or a mips cpu

rotund portal
#

That same PROM is on the Maximum Force R3000 board.

rotund portal
uncut atlas
#

jerry uses the full bus because it's not limited to the 16 bit cpu

#

"cart" rom can go up to 64 bit wide

rotund portal
#

OK, that's weird.

lyric pelicanBOT
# 
ROM_REGION( 0x800, "user2", 0 ) /* 28C16 style eeprom, currently loaded but not used */
rotund portal
#

So the PROM is used on some boards?

#

Not much in it. Doesn't even look like 68000 code.

#

Quite a few arcade boards use that same IDE chip.

#

Including Killer Instinct.

warm oasis
#

Presumably straight forward to also support 4MB and 6MB ram to cover the two different amounts found in these Co Jag boards?

rotund portal
#

I think the Jag core might already be able to access more than 2MB, yep.

#

But harder to confirm now, because Grey hooked it up in a different way.

#

It's a more "direct" way now, so the Tom chip can directly activate an SDRAM Row and Column.

#

Before, we were kind of latching the Row address on the falling edge of RAS_N.

#

Then just doing a concat of that, along with the CAS addr, then feeding to the SDRAM controller.

# 
wire [19:0] dram_addr = {ras_latch, dram_a};
#

(well, I'm presuming it was Grey, or maybe Kitrinx who made the change.)

uncut atlas
#

that was me

rotund portal
#

dram_a is the address bus direct from Tom now...

.ch1_caddr          ({3'b000, dram_a}),
#

Ahh, hehe.

uncut atlas
#

the way tom works is it has two ram select pins

rotund portal
#

So you have it using dram_a (ch1_caddr) to directly activate a new Row.

# 
            else if(ch1_ac | ch1_act) begin
                {SDRAM_BA,SDRAM_A} <= {2'b00,ch1_caddr[12:0]}; // no auto precharge
uncut atlas
#

so it can have two banks of 4 chips

rotund portal
#

Then the Column...

# 
            else if(ch1_rq | ch1_req) begin
                {SDRAM_BA,SDRAM_A} <= {2'b00,2'b00,1'b0,ch1_caddr[8:0],1'b0}; // no auto precharge
uncut atlas
#

here's also one memory address pin jag doesnt use

#

so they can be bigger too

rotund portal
#

And my brain can't work out the max RAM it's able to access.

uncut atlas
#

so you have to check the board for which way they added more ram

rotund portal
#

Yeah.

#

Not sure which signals they used, but I guess the 6MB would just get mapped in contigous fashion anyway.

#

Cojag 68k...

# 
void jaguar_state::m68020_map(address_map &map)
{
    map(0x000000, 0x7fffff).ram().share("sharedram");
    map(0x800000, 0x9fffff).rom().region("maincpu", 0);
    map(0xa00000, 0xa1ffff).ram().share("mainram");
#

"maincpu" is the actual ROMs.

#

0xE00000 isn't used for cart/rom, as the IDE chip is there.

#

But it might be mapping the lower handful of ROM bytes to 0xE00000 at start-up, so it can make the jump to the ROM mirror at 0x800000.

uncut atlas
#

that looks lie multiple ram banks?

rotund portal
#

I think that's a smaller scratch RAM at 0xA00000.

#

Which could be the RAM chips on the riser board?

uncut atlas
#

some sram?

rotund portal
#

Yep.

uncut atlas
#

idk mame is garbage for this, need a schematic

rotund portal
#

32KBytes each.

#

Four in parallel.

#

I'd love a schematic, but haven't found it yet. lol

#

There are some "schematic" pages in some manuals like Area 51, but only about 3 out of 10 pages are shown.

uncut atlas
#

128kb of 64 bit wide sram? that's rough

rotund portal
#

Fast scrachpad, I guess?

uncut atlas
#

I dont think we have enough free blockram

rotund portal
#

Probably not, although the BIOS is only 128KB.

#

TG68K starting to do something.

#

But I had to remove the data bus from SignalFarp, else it complained.

#

Because the data bus on TG68K is bidirectional, which isn't ideal.

uncut atlas
#

This doesn't really seem productive right now until we can make the much less demanding Jaguar stable

rotund portal
#

This is true, but I felt like having a look today.

I don't know how to go about pinpointing the main timing issues with the Jag core.

#

Aside from staring at TimeQuest, and trying to figure out what to actually change, based on its recommendations.

#

Actually, that SRAM is probably only 32-bit (total).

#

8-bit per chip.

#

So probably directly accessible by the 68020 only.

mental briar
rotund portal
#

Also has possibly my favourite song of all time.

#

Partly because of the memories it brings back, of when my brother first rented the VHS tape in the late 80s.

mental briar
#

Everybody wants to rule the world?

rotund portal
#

Yeah.

#

I just love Tears For Fears in general, too.

warm oasis
#

What film is this?

#

Oh, Real Genius

hot rune
#

Val Kilmer should have done more comedy Real Genius and Top Secret are great

warm oasis
#

He is brilliant Kiss Kiss Bang Bang

mental briar
#

he should have won an oscar for tombstone

rotund portal
#

I watched Kiss Kiss Bang Bang, when I was on a flight to Melbourne in 2006. lol

#

I was trying to stop myself laughing loudly.

#

Case in point, about the active-low signals...

#

I had the Read/Write signal inverted.

#

Because on TG68K, it's just called "RW".

#

Which is more often called RWn on the datasheets.

#

Meaning "Read when High, Write when Low".

#

But at least it's trying to read some code.

#

Colours

image.png
#

(...of Robert Mapplethorpe)

#

Apparently it's running some code, but meh.

#

Gonna take forever to debug, with it taking 17+ minutes for every compile.

rotund portal
#

Seems to crash, after it (Tom?) does a Bus Request.

#

I'll have to try adding some proper logic to handle that later.

#

I can't remember quite how it works atm. Which chip takes priority, which signals might need to be set to High-Z etc

small sail
#

👾🍒🥷♥️🐆

rotund portal
#

nice

#

"The new Atari Leopard..."

#

"Presenting, the Nintendo Slug..."

thorny swift
small sail
ashen spoke
small sail
mental briar
still aurora
thorny swift
# small sail

dunno what jacked ass Jaguar your phone thinks that is

small sail
#

It's a British vegan jaguar, brought up on a diet of beans.

mental briar
#

instead of growling when it boots up, it yells "OI"

small sail
#

😂

#

That is an accurate description of our common tongue.

#

Usually "Oi mate"

mental briar
#

@sterile moss can we change the sound effects in the bios?

#

asking for a friend

hot rune
mental briar
#

The Val documentary on Amazon is great (and heart breaking)

last kelp
#

I can't seem to get any games working on the improved core; I just get a black screen after the BIOS. For a while I only had one 128MB ram module and I recently added another 128MB module; is the other stick busted maybe? I think I set the jumpers correctly on the board for the second stick.

vague whale
#

Try the saturn dual ram core, if that also fails, your ram may be installed wrong or defective

last kelp
#

The saturn dual ram seems to work fine; I'm trying to find the latest PSX dual build to test that.

#

Is there a prefered ROM format? I'm using *.rom files.

vague whale
#

The ones that work here are .j64 format

mental briar
#

Yeah I have j64

last kelp
#

ok, must have been that.... *.j64 works!!

#

Anyone know a way to convert *.rom files to j64?

small mural
warm oasis
#

That's interesting, so are there certain packs of Jag roms that don't work?

dense ravine
small mural
#

We took the Jag out for a spin. Pranged it.
I'm not getting any loads on this build with any of my sets. J64 (Champion), JAG (redump), or .rom (not sure where I got it... ArcPunks?).

#

*for AvP specifically

mental briar
small mural
#

Bubsy loads great...so this is hell.

#

Yeah

mental briar
#

oh, for AVP

small mural
#

Yeah, sorry it was on a request list for captures, alphabetically first. So...

mental briar
#

yeah, that's the same on my retrocastle build. works fine on my misteraddons build. so, all that to say, expected at this point

small mural
#

I had that exact issue last time, but this time it's both.

mental briar
#

the memory timings are very finicky, apparently

#

oh right, I remember you mentioning that

small mural
#

MA OG digi and new I/O for dual ram.

low dome
warm oasis
#

Will wait for Kitrinx or Greyrogue to weigh in on what types work and what don't, and if more are going to be supported, but there should be one pack that can be recommended everyone uses.

low dome
#

In some cases, there were a few jaguar roms that were originally in .rom format and I just rename it to .j64 and it works with the core.

uncut atlas
#

No point in supporting anything else

ashen spoke
#

all i know are j64 roms

small mural
#

J64 are the raw dumps, right?

#

Ah, link above says yes. Perfect.

dusk slate
#

Atari doing dat 64 thang before Nintendo.

small mural
#

Just like my 24 bit NeoGeo and 16 bit TG-16! Though, FPGA has dropped bit math for....common....core....

<I actually kinda like common core...estimating makes humans faster and more accurate in the long run (in general)>

thorny swift
rain sierra
sterile moss
# mental briar <@465366454448029697> can we change the sound effects in the bios?

Hey, I'm not sure myself, but the source is meant to be around somewhere so I suppose someone who knows what they're doing likely could 🙂
The custom image is thanks to the 'introptf.exe' that Kitrinx linked, me finding a bmp_cry tool to convert an image into the jaguar 'cry' format introptf.exe wanted, and some sheer luck with hex editing

#

I just noticed that the 82KB .img file that introptf.exe produces (the custom intro animation) had a lot of similar bytes to the bios, overwrote from there

mental briar
#

the misterkun makes me unreasonbly pleased every time it loads

uncut atlas
#

it's the small things

nova frost
#

Truth care, truth brings

rotund portal
#

I tried adding the "Scratch" RAM to the core last night, to see if I could get some Cojag ROMs running more code.

#

That RAM is mapped at 0xA00000 to 0xA1FFFF, so 128KB (64K Words).

#

But nope, there's a more specific problem with how I've hooked up TG68K, or other logic that's missing, and the Cojag code can't see it.

#

It is mostly deterministic on each boot, though.

#

But always ends up trying to read/write DRAM around 0x7F0000, then there are no more DTACK pulses, and it flatlines.

#

This is the only thing written to the Scratch RAM so far...

#

Which is probably garbage, as I need to generate pulses from the 68K cycles.

#

On MAME, the code copies the first part of the ROM into scratch RAM.

#

So obviously there's something very wrong on the core atm, and it won't boot any further.

#

I was just hoping to get it far enough to see anything on screen, other than flashing colours. lol

#

Probably not worth the effort for only one or two Cojag games that use the 68020.

#

I also have no idea how much of the '020 the TG68K core actually supports.

#

That CPU core is used on Minimig, of course.

#

It doesn't have the full 32-bit wide bus either, so reads the instructions/data as 16-bit wide, like the 68000 mode does.

#

TG68K still has this comment in the code...

# 
CPU    : in std_logic_vector(1 downto 0):="00";  -- 00->68000  01->68010  11->68020(only some parts - yet)
#

It could be missing specific instructions, and all sorts. But then I don't know why it would be used in the Minimig core 020 mode atm?

#

Anywho, just something to mess with. It's a KILLER waiting for recompiles, and I must have done about 30 so far.

#

This is one of the reasons I need to get the sim running again.

#

So I can see how far the Cojag code might have ran with fx68K (I can't use TG68K in the sim, because VHDL is evil).

#

It's also SO much easier writing some stuff in C, and much easier to generate proper logs from any part of the core.

pure oracle
#

No wonder VHDL stands for “Very Hard Difficult Language”

rotund portal
#

Yep.

#

Just... I just find it kind of unnecessarily overcomplex to type. lol

#

And it uses different operators for the bitwise / maths stuff.

#

Whereas Verilog is much closer to what C uses.

#

Even now, I'm trying to think of an example of what VHDL uses, and I can never remember.

#

I think it uses the "&" symbol for concatenating bits / busses. sigh

# 
memaddr_a(31 downto 16) <= (OTHERS=>memaddr_a(15));
#

"OTHERS"

# 
WHEN X"e" => exe_condition <= (Flags(3) AND Flags(1) AND NOT Flags(2)) OR (NOT Flags(3) AND NOT Flags(1) AND NOT Flags(2));
#

For God's sake, man. ^

# 
DATA <= data_write WHEN data_akt_e='1' OR data_akt_s='1' ELSE "ZZZZZZZZZZZZZZZZ";
#

It's like the grammar is backwards, German style.

#

"DATA <= (assign) data_write WHEN (this condition) OR (this condition) ELSE (assign this)."

#

Hate it. lol

#

No offence to anyone who prefers VHDL, it's just not for me.

# 
Verilog...

DATA <= (data_akt_e==1 | data_akt_s==1) ? data_write : 32'hZZZZZZZZZZZZZZZZ;
#

(conditional operator, like in C.)

#

Or it can be done in an always block, and look a bit cleaner.

#

(braces at the start might not be needed, but I think it's good practice, to denote the conditional part.)

#

VHDL...

# 
-- VHDL code for ALU 
process(SEL,ABUS,BBUS,tmp1,tmp2)
begin 
case(SEL) is
 when "0000" =>  ALUOUT <= tmp1; -- ADD
 when "0001" =>  ALUOUT <= tmp2;-- SUB 
 when "0010" =>  ALUOUT <= BBUS; -- AND
 when others => ALUOUT <= ABUS; 
 end case;
end process;
#

Verilog...

# 
// Verilog equivalent to VHDL ALU 
assign ALUOUT = (SEL==0) ? tmp1 : ((SEL==1) ? tmp2 : ((SEL==2) ? BBUS : ABUS));
#

Not really a fair comparison, but I found it online. lol

#

You can also use the case statement in Verilog, of course.

#

But it would need to be within an always block, AFAIK.

#

(ie. not just a direct combinational assign.)

#

(EDITED, to add spaces between the thingies.)

#

Verilog does have a slight issue, where if you forget to declare a "wire" for a bus (group of bits/signals), it won't complain.

#

And you'll end up only assigning the LSB bit, which is obviously bad.

# 
wire [15:0] sc_dout;
#

But, as Jotego and others said, you can add a keyword near the top of each file, and it will cause Quartus to trigger an error unless ALL bits of the busses have a wire declaration.

# 
`default_nettype none
rotund portal
#

lol

#

It found one right away.

#

But that signal is only 1-bit wide anyway, so wouldn't have mattered.

#

Still, may be worth adding the default_nettype thing to all files, and see if it finds any glaring problems.

#

It will probably generate a LOT of "errors" on the Jag core, though, if it's already complaining about 1-bit wide signals not having a wire.

warm oasis
#

Worth doing and reading through to see if any errors look legit?

rotund portal
#

Just added to some of the Jag main files, and no errors so far.

rotund portal
#

A bit of homework.

#

Using the falling edge of DTACK_N, to decide when to write data to the Scratch RAM.

#

AS_N is basically "Address Strobe", so gets asserted whenever the 68K puts a valid address on the bus.

#

So AS_N is active for most of the memory read/write cycle.

#

UDS_N and LDS_N denote whether the upper and lower byte of the data bus is valid (ie. which byte, if any, should get written to memory / mem-mapped IO).

#

Forgot all about this.

#

Apparently I had a few bare PCBs made in December 2021.

#

Never built one. lol

#

The idea being, to run the FPGA version of the DSP chip in lock-step with the real chip.

#

And look for any mismatch.

#

I couldn't easily do a version for the Tom chip, as it has a lot more pins.

rotund portal
#

Another day, another Jag compile.

#

Messing with the Cojag thing (still), but not getting very far.

#

It does seem to run a fair bit of code, but always crashes.

#

Or jumps to a place in memory that isn't mapped properly in the core yet.

#

That 0x714DF7 would place it in the main DRAM on Cojag.

#

Which is kind of around 7.2 MBytes into RAM.

image.png
#

At least that looks like actual data this time. lol

#

NqN is a tell-tale sign of some 68K code.

#

0x4E71 is the NOP at the start of the ROM.

#

But the next word looks wrong, unless it's copied from elsewhere in ROM.

#

In the code / in MAME, it does copy a whole chunk of the ROM to the Scratch RAM.

#

The first writes, to Scratch RAM...

#

Might call it "WRAM" (Work RAM) from now-on.

# 
81CA86: FFA0                               dc.w    $ffa0; opcode 1111
81CA88: 042C 23DF FFA0                     subi.b  #-$21, (-$60,A4)
81CA8E: 0434 33DF FFA0 043E                subi.b  #-$21, ($43e,A7.l*8)
81CA96: 23DF FFA0 0438                     move.l  (A7)+, $ffa00438.l
81CA9C: 601C                               bra     $81caba
81CA9E: 40F9 FFA0 043E                     move    SR, $ffa0043e.l
81CAA4: 46FC 2700                          move    #$2700, SR
81CAA8: 42B9 FFA0 0434                     clr.l   $ffa00434.l
81CAAE: 23DF FFA0 0438                     move.l  (A7)+, $ffa00438.l
81CAB4: 23DF FFA0 042C                     move.l  (A7)+, $ffa0042c.l
81CABA: 48F9 7FFF FFA0 0440                movem.l D0-D7/A0-A6, $ffa00440.l
#

In MAME, that part of the code doesn't even run, so it's either branching elsewhere, or just not reading the correct instructions, or TG68K isn't handling enough of the 020 stuff atm.

#

Using 53% of the BRAM atm, which isn't too bad, considering there's an extra 128KB for WRAM, and SignalTap is enabled.

#

Reverting to fx68k. To get the Jag BIOS to boot again.

#

Then see what Cojag does, and if it runs the same core (or more, or less).

thorny swift
rotund portal
#

Nice.

#

At least that still works...

rotund portal
#

Although I expect quite a lot of that decoding is done in the PAL/GAL chips.

#

If those chips are the type with internal registers, it's generally way harder to dump the config.

#

It may not be doing a whole lot of magic stuff vs the Jag, tbh.

#

Probably a lot of it is to interface to the VIA IDE chip, etc.

#

No idea if they used the standard Jag IO pins for the JAMMA controls.

#

That's as far as Area 51 gets on fx68k, before seeming to crash.

# 
81CB64: subi.l  #$10000, D1
81CB6A: bcc     $81cb5e

   (loops for 262148 instructions)

81CB6E: move.w  #$1f00, $fff000e0.l
81CB76: move.w  #$0, $fff000e2.l
81CB7E: move.w  #$0, $fff02114.l
81CB86: move.w  #$0, $fff1a114.l
81CB8E: moveq   #-$1, D0
81CB90: dbra    D0, $81cb90
81CB90: dbra    D0, $81cb90
ashen spoke
#

@rotund portal I have no idea what you’re doing but I’m here for it!

rotund portal
#

Believe me, I have no idea what I'm doing either. lol

#

It's just a distraction from building PCBs atm, tbh.

#

I've had a board sat on the bench for over six weeks, and just haven't felt like building anything.

#

Including the new GD Emu / HDMI board for DC. 😦

#

Probably not going to get too far with Cojag, unless we can get help to confirm what TG68K does and doesn't support, in terms of the 68020 instructions.

#

(or seeing which 020-specific instructions are used in the Cojag games. Some might not even use them?)

thorny swift
#

@rotund portal how close was i?

void quartz
#

I’m somewhat new to discord, can anyone help me figure out how to unhide the Test Builds channel? I don’t seem to have access and I don’t see it as an available channel.

thorny swift
#

I think also there is some weirdness in where the data first boots from in POST as far as memory addresses are concerned vs the Jaguar console. Considering the arcade boards have a ROM but then basically hand off to an IDE drive there would need to be a some additional hardware / instructions to start ingesting and executing data off the HDD in and of itself

#

probably a lot of that logic is in the GAL chips. It is on 3DO M2 when it boots via HDD for the dev kit

#

(or I am talking out my ass 🤣 )

void quartz
#

NVM…got it figured out.

rotund portal
#

The IDE stuff will happen a lot later, if we can get anywhere with the 68K stuff first.

#

It's currently only managing to run a handful of instructions before crashing, so not super useful right now.

#

I've been messing with the Jag core for about four days, so looking at DC again.

#

I asked Claude AI last night, to generate some code to help me calculate the Triangle Visibility thing on 32 pixels at once.

#

It's... working slightly better than I gave it credit for. lol

#

I don't know if that's better or worse. lol

#

But at least it didn't take 17+ minutes for a compile.

#

Verilator "compiles" the sim model in less than half a second.

serene widget
#

I'm trying to make out what game I'm looking at here.

rotund portal
#

"Rolling Starrrrrrt !"

#

Featuring one of the greatest arcade themes of all time

thorny swift
#

thats the Hornet from Daytona baby

rotund portal
#

I'm determined to get this working, because it massively simplifies the maths.

serene widget
#

||/s||

rotund portal
#

lol

#

I should probably continue this discussion on the Simulant server.

#

But, one last pic...

#

I think it's getting closer.

karmic minnow
ashen spoke
#

IMGUI IS THE BEST elmorise

thorny swift
warm oasis
#

Funny seeing Retro RGB Bob begging for spinner support in the core. How hard would that be Kitrinx?

mental briar
#

So Jotego has JTFriday. SRG has Saturnday....Guarday? Jagueekend? SundayFunday?

#

Greyday? Potaday?

#

We need to workshop this

uncut atlas
uncut atlas
thorny swift
#

Junday 🤣

dusk slate
#

Caturday

thorny swift
thorny swift
dusk slate
#

The meme that just keeps on giving.

mental briar
thorny swift
#

@rotund portal with you pivoting on the memory addresses on where CoJag boots from in memory vs a console now the first thing I want to do with the CoJag after tearing it down is burning retail games to rom at the proper address and trying to boot retail on the CoJag

#

For no good reason other than it would be funny to see

mental briar
#

I poured my creative soul into those names

thorny swift
#

Buesday. Bubsy Tuesdays

rain sierra
thorny swift
rain sierra
thorny swift
#

Does anyone have a good list of Jaguar homebrew? I know nothing of what’s out there

mental briar
#

Aliens Versus Wednesday

thorny swift
#

CyberMorphMonday

mental briar
#

now now...every day is cybermorph day

#

Barkley's shut up and tuesday

warm oasis
#

JagOffDay is good, as that can be any random day

mental briar
#

Or every day, if you’re strong enough

thorny swift
mental briar
rotund portal
#

Trying to think how that would work.

#

I mean, it might, somehow.

# 
// OS ROM (BIOS). Mapped at 0xE00000 on the Jag.
assign os_rom_ce_n = xromcsl[0];

// CART. Mapped at 0x800000 on the Jag.
assign cart_ce_n = xromcsl[1];
#

So I guess xromcsl will get asserted first at power-up / reset.

#

So Tom, pin 58.

image.png
#

Cojag just mounts the boot ROM at 0x800000 instead.

# 
map(0x800000, 0x9fffff).rom().region("maincpu", 0);
#

Jag...

#

Ohh, I see now.

#

I should have read the top part of that same page. lol

#

The 68000 will of course start reading the vector table stuff from address 0.

#

So will (likely) assert ROMCSL (BIOS) within that range.

#

Shortly after, some 68K code will write to the MEMCON reg(s), to chose where to map BIOS and Cart.

#

(from the point-of-view of the 68K memory space. The Tom chip will handle the remapping, AFAIK?)

thorny swift
#

And I’d hazard a guess that at least cardinal directions and A/B/C/Start/Option will be automatically transposed from the JAMMA edge to the appropriate hardware on the CoJag

rotund portal
#

Yep, except Cojag maps the IDE chip to 0xE00000, sort of.

# 
map(0xe00030, 0xe0003f).rw(m_ide, FUNC(vt83c461_device::config_r), FUNC(vt83c461_device::config_w));
#

My brain can't figure out how it's doing the mapping. ie. whether it just has some logic to swap those areas around, etc.

thorny swift
#

I doubt they changed IO pins. More likely just got the signal from jamma to the pins

rotund portal
#

Probably, yep.

#

Although we don't know whether they used a similar "matrix" scheme to the Jag games, or something else.

#

Without looking through more MAME code.

#

I think I see - it starts up with ROMHI set to 0.

#

Set maps the BIOS (well, whatever is hooked up to ROMCSL0) to address offset 0.

#

Then the 68K code can chose whether to set ROMHI to 1, to change the mapping.

#

(on the Jag, that means it will immediately have to jump to a location at 0xE00000 to some BIOS code, or to 0x800000 for Cart code.)

#

Don't quite get it.

#

On CoJag, it will start off with the ROM at addr 0.

#

I'll check on MAME to see what it writes to MEMCON...

#

area51t, writes this same value to MEMCON1 three times in a row, then three times again.

#

Then it starts playing the intro vid.

#

0x587D35DD

#

So it DOES use ROMHI = 1.

#

So, after power-up/reset, the ROM is mapped at addr 0, so the 68K can read the vector table, make the jump, etc.

#

Then some code sets ROMHI = 1, which re-maps the ROM.

#

The problem is, it can't be at 0xE00000 like it is on the Jag, because Cojag maps the IDE chip there.

#

So I think the board must switch over to using ROMCSL1 for the ROM at that point?

thorny swift
#

3DO M2 isn’t much diff. First bios memory address executes the POST and security / rom checksum checks then it jumps to an area in the bios that is almost 1:1 to the console bios if you compare the two in hex. CoJag may be doing the opposite

rotund portal
#

You know what, it's probably just a wired OR. lol

#

Or, more accurately, and AND.

#

ROMCSL0 AND ROMCSL1.

#

Oh, it can't be. The IDE would clash with the ROM otherwise.

#

Either way, the ROM code definitely jumps to running code from the 0x800000 range at some point.

#

Actually, very early-on.

#

You can see the 0x587d35cc gets loaded into D0 near the top of the page.

#

Then gets written to MEMCON1 at 0xF00000 at the highlighted line.

#

(ignoring the upper 0xFF bits of the address bus. It probably doesn't even hook those up.)

#

Still don't quite get it.

#

If it starts up with ROMHI=1 (via a pull-up), then it surely wouldn't be able to read the ROM code from addr 0, but would be trying to read (uninitialized) main RAM instead?

#

But we know the reset Program Counter is the second Word in the ROM.

#

So that's the very first place it will jump to after reset, and after reading the first Word (which sets the Supervisor Stack Pointer).

#

So I guess it must just be set to ROMHI=1 mode at power-up, like the Jag.

#

A Jag cart ROM would need to be modified to run on Cojag.

#

'cos a cart contains the header as well.

#

The Jag BIOS normally reads that header, to know where to start copying the boot code from the cart into RAM.

#

A bit like how the N64 does it.

#

I think CoJag must just switch from ROMCSL0 to ROMCSL1, after the first few reads.

#

So it can immediately jump to code at 0x800000 (which is where the Cart is usually mapped on the Jag).

#

Not to mention many games will probably be using some BIOS functions, so that's tricky. lol

#

You'd probably have to add an extra ROM socket for the BIOS, and some decoding logic.

# 
// Jag...
assign os_rom_ce_n = xromcsl[0];  // BIOS. Mapped at 0xE00000.
assign cart_ce_n = xromcsl[1];    // CART. Mapped at 0x800000.

// CoJag...
assign os_rom_ce_n = xromcsl[0];  // VIA IDE chip etc.  Mapped at 0xE00000.
assign cart_ce_n = xromcsl[1];    // "BIOS" (main ROM). Mapped at 0x800000.
#

Making a bit more sense.

#

CoJag ROM is just using ROMCSL1, so gets mapped where the cart usually is.

scenic briar
#

how is the jaguar coming along? new logo from the car company can't be just a coincidence 😂

jaguar-new-logo-1-7115713-1732050007261.png
rotund portal
#

With a bit of extra logic, to allow reading the vectors from addr 0, unless Tom does that anyway.

rotund portal
#

I think the car company forgot one of the Golden Rules of the Internet... "Don't F with cats!".

scenic briar
#

LOL

#

its all connected, they surely have a Mister

rotund portal
#

It is a bit strange, including the fact that it's been a while since I helped with a carpet clean, and spotted this the other day...

#

#1055574003810578503 message

#

Oh - I already had the two ROMCSL signals added to SnargleFlap earlier.

#

I don't know what I was expecting, because obviously ROMCSL0 gets asserted at boot. lol

#

(rising edge of xresetl at the top.)

#

Ohh, ffs.

#

It does actually change to ROMCSL1 later on (CoJag Area51 ROM)...

#

Which is where it was crashing for me before. Doh!

#

And that is directly after it writes to 0xF00000 (MEMCON1).

#

(I'm basically loading the first 128KB of Area51 as if it's a "BIOS", then loading the full 2MB ROM as well, as if it's a "Cart".)

#

Then it's supposedly doing the loop, so doesn't need to access the bus during that time.

# 
81CB52: move.l  D0, $fff00000.l
81CB58: move.l  #$3ffff, D1
81CB5E: nop
81CB60: dbra    D1, $81cb5e
81CB5E: nop
81CB60: dbra    D1, $81cb5e

   (loops for 131068 instructions)
#

May be an endianess thing...

#

Because the OS ROM (BIOS) on the Jag is read as only 8-bit wide, so presumably it gets the byte order correct.

#

But the cart is (atm) read as 32-bit wide, so I might need to byteswap the CoJag ROM when being read from the "Cart" addr range.

#

If that makes any sense. lol

#

The problem is - 17+ minute compiles, and about four different combinations to try.

#

Endianess looks fine.

#

But it seems to try to write to the upper bank of DRAM, which ofc the core isn't really set up for.

#

Ohhhh.

#

Cart = 32-bit wide.

#

68000 isn't. lol

#

Well, the ROM isn't, I mean.

#

No I can see why they might have mapped the CoJag ROM at 0x800000, because it can be accessed as 32-bit wide, so it's faster.

#

It didn't matter so much for the BIOS on the Jag to be that fast at start-up, so it's only 8-bit wide.

#

I think I see the problem now.

#

And it is the 68K trying to access the "cart" as 32-bit wide.

#

Even though the Cart data should get loaded into DDR3 fine, the 68K isn't... this is actually very hard to explain. lol

#

I think, once it sets ROMHI=1, it expects Tom or Jerry can access the cart ROM as 32-bit wide.

#

So will increment the address by 4 each time.

#

But the 68K can't do that, as it only increments the address by 2, for each contiguous fetch.

#

Or something.

#

Possibly related to it needing the 68020, but I'm not sure yet.

#

Basically looks like it's reading the same Words in twice, and some garbage in other places, probably from the upper 16-bits of the bus.

#

Yep...

#

Before the ROM code sets ROMHI=0, it's able to access the ROM within the 0x800000 range, and as 16-bit wide.

#

Tom handles the translation there, because the BIOS is actually stored as 8-bit wide. So Tom does the two byte fetches, shoves them into a pair, then feeds to the 68K.

#

But after that, Tom is expecting the 68K to read in 32-bit mode, so yep, 68020 problems.

#

I don't see bit 14 being set by that value. hmm

# 
// 32-bit cart mode...
//
assign cart_q = (!abus_out[2]) ? DDRAM_DOUT[63:32] : DDRAM_DOUT[31:00];
#

OK, so the 32-bit CPU mode will be set on CoJag via pull-up resistor on an XMA pin...

# 
assign xma_in[5]  = (xma_oe[5])  ? xma_out[5]  : 1'b0; // CPU32
#

But I need to tweak the cart reading logic, to allow the 68K to read as 16-bit wide.

# 
// 32-bit cart mode (Jag)...
wire [31:0] cart32 = (!abus_out[2]) ? DDRAM_DOUT[63:32] : DDRAM_DOUT[31:00];

// 16-bit cart mode (CoJag)...
wire [15:0] cart16 = (abus_out[2:1]==2'd0) ? DDRAM_DOUT[63:48] :
                     (abus_out[2:1]==2'd1) ? DDRAM_DOUT[47:32] :
                     (abus_out[2:1]==2'd2) ? DDRAM_DOUT[31:16] :
                                             DDRAM_DOUT[15:00];

assign cart_q = (status[12]) ? cart16 : cart32;    // Switch between 16-bit (CoJag) and 32-bit (Jag) "cart" reading modes.
#

It's not really 16-bit access on CoJag, 'cos it has a 32-bit CPU.

#

fx68k and TG68K don't support 32-bit, so I have to make do. lol

#

No idea if this will help, but compiling anyway.

ashen spoke
#

you heard it here first, Atari Jaguar isn’t 64-bit

rotund portal
#

lol

#

I may have been mentioned a few times in the past. 😛

ashen spoke
rotund portal
#

No change so far, but I think it's because I should have replicated the 16 bits to the upper part of the bus.

# 
assign cart_q = (status[12]) ? {cart16,cart16} : cart32;
#

The squiggly braces allow you to do concatenation of wires / busses.

#

Without that, the upper 16-bits of the cart_q bus (32-bit) were probably left as High-Z (floating), and defaulting to 0xFFFF or something.

rotund portal
#

Great - now the core won't boot at all. lol

#

Typical.

#

Either the marginal timing causing problems, or the fact I enabled the "CoJag Mode" menu option, and it needs that disabled at start-up.

#

This seems to happen SO often on retro cores - the moment you think you're getting closer to something working, the whole thing breaks.

rotund portal
#

The core seems to kill everything atm. No idea why.

#

Like it's stomping on the wrong mem in DDR3, and breaking Linux.

#

Even SSH login stops working.

rotund portal
#

OK, so I changed one teensy tiny thing, and that's probably what broke it.

# 
wire cart_rd_trig = !cart_ce_n && (cart_ce_n_falling || (abus_out != old_abus_out));
#

I commented out the !cart_ce_n &&

#

So it was probably triggering a cart ROM read from DDR3 all the time, so the ARM/Linux side had no chance of accessing DDR.

#

Lesson learned.

#

Now it's clear why trying to debug this stuff on hardware is SO hard. lol

#

Waiting for that compile time SUCKS.

rotund portal
#

No change.

#

I need to understand more about what's happening first.

#

Definitely done for tonight. It's 4am here in Mordor again.

#

g'night. zzzzzzzz

uncut atlas
#

tom does it's own masking of different cart bits

#

and of course it uses romcsl0

#

it has to

#

it's like saying "the 6502 must boot from 0xFFFF"

#

a rom has to be selected and that's the default select, otherwise there's no boot code

#

the arcade board of course messes with the memory address input's at boot where it gets the hardware parameters

#

maybe the B bus as well

#

(I think it's the button bus?)

#

i'd honestly be kind of surprised if the cojag didnt have a boot rom of some kind

#

otherwise tom wouldnt know the correct memory size to read

#

that ergister has to get set

dense ravine
#

Calling the chips Tom and Jerry is the best thing I’ve ever seen. It makes reading messages in here without context so much more amusing

fossil lintel
#

Imagine if one was called robby

thorny swift
#

lol people astonish me sometimes. Are we all having a collective fever dream? Is Jaguar core not real? 🤣

Screenshot_2024-11-21_072700.png
dense ravine
#

Next YT video is @thorny swift pulling up in a Lambo asking for $3 for a Jaguar core with no compromises

thorny swift
dense ravine
#

Dual Lambos

thorny swift
#

I worry about people sometimes lol

rotund portal
#

If only the Jag core was a software emu on the ARM, it would save us all this trouble. lol

#

Back again...

#

There seems to be an issue with cart reading, which might affect normal Jag games.

#

(ie. even when CoJag mode is disabled, and cart reading is set to 32-bit wide.)

#

You can see on DDRAM_DOUT, it grabs the correct data (matching up with what you see in MAME at the top-left window.)

#

It shoves the data into iEdb correctly for a while, which is the fx68k data input.

#

The data should be valid when xdtackl pulses Low.

#

But iEdb receives the wrong data sometimes, as if it's reading the "open bus", or sometimes whatever is on oEdb, which is the OUTPUT bus from fx68k?

# 
// The external data bus (ED) is driven when RW is high and XEXPL is low.
wire [7:0] e_dbus_7_0 =
    (os_rom_oe)         ? os_rom_q[7:0]     : // BIOS.
    (cart_oe[0])        ? cart_q[7:0]       : // Cart ROM.
    (joy_bus_oe)        ? joy_bus[7:0]      : // Joyports.
    (adc_oe)            ? adc_data[7:0]     : // Joystick DAC.
    8'hFF;                                    // External bus is pulled up.

wire [7:0] e_dbus_15_8 =
    (cart_oe[0])        ? cart_q[15:8]      : // Cart ROM.
    (joy_bus_oe)        ? joy_bus[15:8]     : // Joyports.
    8'hFF;                                    // External bus is pulled up.

wire [15:0] e_dbus_15_0 = {e_dbus_15_8, e_dbus_7_0};

wire [15:0] e_dbus_31_16 =
    (cart_oe[1])        ? cart_q[31:16]     : // Cart ROM.
    16'hFFFF;                                 // External bus is pulled up.
# 
assign cart_oe[0] = (~cart_oe_n[0] & ~cart_ce_n);
assign cart_oe[1] = (~cart_oe_n[1] & ~cart_ce_n);
# 
assign cart_ce_n = xromcsl[1];
assign cart_oe_n[0] = xoel[0];
assign cart_oe_n[1] = xoel[1];
#

cart_ce_n is direct from xromcsl[1] on Tom.

#

Same for cart_oe_n[1:0].

# 
reg [63:0] open_bus; // Chances are this should be capacitance based

always @(posedge sys_clk) begin
    open_bus <= dbus;
end
ashen spoke
#

Are you hacking us?

rotund portal
#

Trying to.

thorny swift
rotund portal
#

Super confusing, how the busses are wired.

#

Don't even know where to start with this one. lol

#

It can't really be due to this...

# 
wire fx68k_dout_en = fx68k_bus_en & ~fx68k_rw;
#

Because fx68k_rw is held High for most of the SignalFap capture.

#

But it could definitely be due to this...

# 
wire e_dbus_oe = ~xexpl & rw;
#

The only way it can read data from the "external bus" (which the cart is on), is via these...

# 
wire [15:0] dbus_15_0_no_j =
    (den[0])            ? xd_out[15:0]      : // Tom.
    (dram_oe[0])        ? dram_q[15:0]      : // DRAM.
    (e_dbus_oe)         ? e_dbus_15_0       : // External Bus.
    {dbus_15_8, dbus_7_0};                    // 68000, Open bus.
# 
wire [15:0] dbus_31_16 =
    (den[1])            ? xd_out[31:16]     : // Tom.
    (dram_oe[1])        ? dram_q[31:16]     : // DRAM.
    (e_dbus_oe)         ? e_dbus_31_16      : // Cart ROM (External Bus).
    open_bus[31:16];
#

ie. when e_dbus_oe is High.

#

So rw has to be High, and xexpl Low.

#

xexpl stays Low for far longer, when it's reading using xromcsl[0]...

#

But then it does the write to MEMCON1 at 0xF00000, to switch to using xromcsl[1] instead.

#

Then the xexpl (low) pulses are too short.

#

Which would shove either the 68K write data, or open bus crap onto the 68K input.

#

xexpl is generated directly by Tom.

#

Gonna try forcing e_dbus_oe, when cart_ce_n (romcsl[1]) is Low.

# 
wire e_dbus_oe = (~xexpl | ~cart_ce_n) & rw;
#

It seems like xexpl is being brought high far too early, before dtackn goes High.

#

So sometimes the 68K isn't seeing the correct data?

#

Actually, that won't help either. xexpl and romcsl[1] are the same width in the SignalTap capture.

#

I don't know if Tom is supposed to be latching the data from the Cart, to allow the 68K to read it?

#

'cos when it translates between bus widths, Tom has to do the translation.

#

(like reading two Bytes from the BIOS, to make one 16-bit read for the 68K)

thorny swift
#

well the seller marked the CoJag as shipped but didnt add tracking so...damn it lol

rotund portal
#

I hate that.

#

Anything more than about $50 should have tracking.

thorny swift
#

yeah always drives me nuts

rotund portal
#

Not sure how to fix this atm. It could be an alignment issue.

#

Maybe due to not using a 32-bit 68K.

#

Or it could be something like the CoJag code not setting a slower ROM read rate, and it's messing things up.

#

(due to a small bug in the core.)

#

I think IOSPEED does determine how fast it reads the Cart too? (ROMCSL1).

#

ROMSPEED relates to ROMCSL0 (usually the BIOS), AFAIK.

desert oar
rotund portal
#

Bits 12:11 are set to b10.

#

(fairly sure the 12 is the MSB bit, not how it says it in the PDF, but I could be wrong.)

#

Which would set IOSPEED to 2 (4 clock cycles).

#

So it's not like it's using the fastest setting.

#

I need to figure out why it sometimes seems to grab the data from oEdb (even though eRWn is always High/deasserted), and sometimes has 0xFFFF, like the open bus thing.

#

I mean this might (not saying it is), but might be part of the issue with AvP not loading properly, but I doubt it.

#

AvP is variable for different people's boards / SDRAM, so probably just very marginal core timings.

desert oar
thorny swift
#

seller has 100% feedback and 2500 reviews so not too worried. I just want the CoJag

#

well I actually dont want it at all lol...but itll be fun for this

rotund portal
#

I hope you won't be too disappointed, when I inevitably don't get any CoJag working on the core. lol

thorny swift
#

make two vids, document the board better for posterity, feed you info then sell the board on

rotund portal
#

Yeah, we can figure out quite a lot from the board, with some multimeter beep tests.

#

Like how it uses ROMCSL[1] and ROMCSL[0] etc.

#

CoJag ROM does set the ROMWIDTH to 32-bit.

#

Which sort of makes sense, but sort of not.

#

I think ROMWIDTH is only for ROMCSL[0], which is what the Jag normally uses for the BIOS.

#

But the BIOS chip on the Jag is only 8-bit wide, IIRC.

#

CoJag likely just maps it's ROM(s) using both signals. CoJag ROMs are almost certainly 32-bit wide.

#

(four 8-bit ROMs in parallel.)

#

Still doesn't quite explain why it's messing up when reading from the "Cart" region, using ROMCSL[1].

mental briar
thorny swift
mental briar
#

Im just asking the question!!

rotund portal
#

Another day, another Quartus compile.

#

Added more signals to SnargleFlap.

#

I really want to fix this. I just want to get the CoJag thing a bit further along, even if it crashes again.

mental briar
#

now you're just making up words

rotund portal
#

What if...

dense ravine
#

I love how you’re posting dev updates that only you, Kit and GreyRogue understand 😂

rotund portal
#

I forced it to carry on using ROMCSL[0], like it does before writing to 0xF00000. hmm

#

lol. Probably true.

#

I'm hoping one of them will have some input on this, because I'm stuck again atm.

#

You know what would be amazing - a kind of GUI that shows you a schematic of the main busses.

#

Then highlights each part, showing where the data is flowing.

#

But that sounds far too much like hard work. lol

#

OK, thinking about it, I can't really keep ROMHI low.

thorny swift
rotund portal
#

Else it won't be able to access DRAM at addr 0.

#

Yeah. I saw something similar on YT a few times. Can't remember which channel.

#

Oh, probably Jon.

#

What's his name.

#

Traveller's Tales programmer.

#

He made some great vids. I wish he'd do some more.

#

Trying to think what the other channel is called, who do amazing vids on the SNES etc.

#

Game Mechanics thingy.

#

#share-media message

warm oasis
#

That is just bizarre if someone is claiming the MiSTer Jag core isn't real... It has existed for years, and recently just got better... You can go play it if you have the hardware...

I read a thread on in Atari Age the other day and the weird negativity was rather off-putting. That doesn't seem a fun place to hang out

thorny swift
rotund portal
#

Strange behaviour of the external databus thing on SignalFap, like only the lower 9 bits are being used?

#

I did try adding (keep) before the wires / busses.

mental briar
# thorny swift it has its moments pro and con

I'm going to need a video of a TV with only one HDMI cable going into it (please show the HDMI label of the input as well), that cable into the back of a mister, you selecting the input with on screen display showing the input selection, loading the core, playing aliens versus predator, all while holding a paper from today's date.

#

Unbroken shot please

#

I know my way around iMovie, so no tricks

rotund portal
#

Does he have to wear pants?

#

#SuperSEGAjoke

mental briar
#

I'm not the police

rotund portal
#

lol

#

cart_oe_n signals kinda make sense.

#

But means that Tom is probably trying to do the bus width translation.

#

Still makes no sense. I don't get what is driven data onto the bus at each point.

mild karma
rotund portal
#

Very tempted to just NOP out the write to 0xF00000, and see what happens.

thorny swift
mental briar
rotund portal
#

Pached the ROMz. Got it running further, but it won't be able to access DRAM like this.

#

It does a Write to the Interrupt enable reg thingy.

#

Nothing at all gets written to WRAM.

#

A few more reg writes, before crashing again.

#

Just interesting that it jumps to the same address, 0x714EF6.

ashen spoke
#

@rotund portal when are you going to share with us your ElectronStash?

||jaguar core update||

rotund portal
#

There is no real update, sadly.

#

Just trying to see how far I can get some Area 51 ROM code to "run".

#

Other than that, the RBF I posted the other day ran AvP for me, and had DV and JagLink added.

#

I can't currently test DV, nor test JagLink.

#

I just added the code for those, from what other people did / posted.

#

I think we got up to the point of the first 68020-specific instruction.

#

Hence the crash.

# 
81CB94: move.l  #$70007, D0
81CB9A: move.l  D0, $fff1a10c.l
81CBA0: move.l  D0, $fff0210c.l
81CBA6: moveq   #$1, D0
81CBA8: movec   D0, CACR; (2+)
81CBAC: clr.w   $ffa00402.l
81CBB2: clr.w   $fff17802.l
81CBB8: move.w  D0, $ffa30000.l
81CBBE: movec   VBR, A0; (1+)
81CBC2: tst.l   A0; (2+)
81CBC4: bne     $81cbec
81CBC6: lea     $ffa00000.l, A0
81CBCC: movec   A0, VBR; (1+)
81CBD0: lea     $800000.l, A1
81CBD6: move.l  #$ffa00400, D0
81CBDC: subi.l  #-$600000, D0
#

Which is anything with the 2+, 1+, etc. I think?

#

So a bit of a dead-end already. Oh well.

#

I might try with TG68K again later, but that its own problems.

#

Unless somebody can help add those instructions to fx68k (or TG68K), this will be tough.

#

"Several" ?!

#

Might have to shelve this idea for a while, sorry.

#

Unless there is a core available with full 68020 compatibility, or we group together to add support to fx68k or TG68K.

#

Or if there's a CoJag game which only makes use of the 68000 instructions, not 020.

#

Or if we use a real 68020 CPU on a riser board, but I can't see many people wanting to do that.

#

Would be nice to know specifically what TG68K supports in "020" mode.

#

lol. Found one of my old posts from TEN years ago (again).

#

(search for 020 on that page)

# 
1) If the tg68k (as an example) is determined "as 68020 compatible" and does not work in practice as a 68020 with respect to the BFINS instruction. Is it fully compatible or not?
mental briar
#

I'm excited to see what Grey and Kit have cooked up for Trevor McSunday

rotund portal
# 
The problem with the Graftgold games and the TG68k in 020 mode is well known - it's not limited to MiSTer. They even work on the TG68 in '000 mode so it's not an issue with cycle-exactness.
lyric pelicanBOT
# 
-- 30.10.2019 TG bugfix BFINS again
rotund portal
#

Maybe TG68K does support more 020 stuff than I realized.

# 
-- done 020:
-- CAS, CAS2
-- TRAPcc
-- PACK
-- UNPK
-- Bitfields
-- address modes
-- long bra
-- DIVS.L, DIVU.L
-- LINK long
-- MULS.L, MULU.L
-- extb.l
humble bluff
rotund portal
#

Oooh, nice.

#

Would be ideal to get Slamy onboard with the Jag / CoJag stuff.

#

At the same time, I'd rather see the CD-i core get further along.

#

The CD-i uses the scc68070, which has a weird variant of the 68K family.

#

But some of the fixes being done for 070 might help 020. Not sure.

#

Trying yet another compile, with TG68K enabled again.

dusk slate
thorny swift
serene widget
#

Oh damn!

dusk slate
lunar latch
#

Which core version was it that Aliens vs Predator worked on?

#

Ive tried quite a few and none of them seem to work

#

I get the BIOS screen, then I get audio but no HDMI video

thorny swift
#

(someone is mad their perceived hardware and game collection value is gonna go down)

dim sundial
mental briar
#

Yeah, AVP is a weird beast. I have the same core on two misters, pulling from the exact same shared rom that is stored on a NAS - one runs AVP no problem, the other does not

#

Going to take some time before the timings for that one are nailed down

#

If you haven't tried this one, I think it's the one that has worked the best for folks: #test-builds message

lunar latch
#

I will definitely give that particular one a try

#

Sadly no dice, guess its time to go out and get a MiSTER Pi

#

LOL

#

Just so that I can have another test unit!!!

mental briar
#

it's weird. try this one? #test-builds message

lunar latch
#

I tried both the one posted on the 12th and the 13th

mental briar
#

She is a cruel mistress

lunar latch
#

LOL, true that

mental briar
#

One more to try! #1055574003810578503 message

#

Actually, I don't think I tested this one #1055574003810578503 message

vague whale
#

For me, the _faster core worked, no others

mental briar
#

ooo, I will try that one now then

#

nope, doesn't work on mine

#

Ok, I think this one (at one point) booted AVP for me. It doesn't anymore but it did! #1055574003810578503 message

serene widget
thorny swift
serene widget
#

It's their kind of mentality that the Atari Jaguar always had fucking shit emulation for many years. Or at least part of it.

||Sorry, for cursing, but these types of gatekeeping people piss me off.||

thorny swift
#

There is just this subset of people who take positive news and spin it into negativity. They must be real charming at parties 🤣

serene widget
#

That's how it is on this bitch of an Internet. Drama will always ensue. Not even the FPGA retrogaming community is safe.

Thankfully, the best solution would be to ignore them completely like the plague, and move on.

mental briar
#

Omgwtfbbq wrote about the internet tough guy like 20 years ago on the something awful forums and it is still accurate today. People, as it turns out, are the worst

serene widget
#

God knows if people were always like this, even before the commercialization of the Internet in 90s.

#

But like I said to Bacon, it's best if we just move on, and continue discussing about the Jaguar core.

If the AtariAge forum people want to eventually join in on the Mister fun, fine. If they don't, also fine.

We're still gonna be here, having fun.

The doors are still open.

thorny swift
mental briar
#

As an aside, let’s fucking go?

image0.jpg
#

I wish they would open source that. 😦 it would be so helpful

serene widget
#

If only there were a wireless version of the Jaguar controller, so you can easily play these games on non-official hardware.

serene widget
# mental briar I wish they would open source that. 😦 it would be so helpful 
A: As addressed previously, I have legal reasons for not releasing BigPEmu's source code at this time. However, Open Source as an ideology within this culture of capitalist exploitation is also a big problem. We're effectively devaluing our own labor, and in failing to recognize so many of our critical weaknesses, we've created an extremely toxic culture which is fueled in large part by egotism and narcissism. In taking such an aggressive stance against free software authors who choose not to release their source code, you're part of the problem.```

Source: https://richwhitehouse.com/jaguar/index.php?content=faq, https://x.com/DickWhitehouse/status/1540107735777177600?t=UdqRCe7UoEn5ER5hH2I-ZA
Rich Whitehouse (@DickWhitehouse) on X

Even without this terrible GitHub service, the idea that public licenses (like the GNU GPL) are meaningfully preventing the exploitation of code/software is, sadly, delusional.

Twitter ·
#

Do with this statement what you will.

uncut atlas
#

Eh. I'm all for making money from your work, but but with emulators

#

That's just shitty

serene widget
#

It's like the brother hasn't even heard of Patreon, or Kofi.

#

I mean, he does have one.

thorny swift
#

I don’t care if people make a little bit of change if they do it legally (not the yuzu method lol)

#

But I’m also the person who yells at commenters when they complain about ads in videos and any sponsored content. Stop assuming every ounce of creative energy in the world is for you and for free by default. It’s still free. Watch a fucking ad. Let me make a couple bucks that gets piped right back into the channel to make more entertaining shit for you 🤷🏻‍♂️

#

But I’m surly. I’ve worked in the arts for two decades now. The amount of people who think we all work “for experience” is insane. Nobody wants to pay shit. They think all fine arts should be made for a zero dollar cost

#

(End rant) so how bout that Jaguar? (Slaps knee) lol

mental briar
uncut atlas
#

No you aren't. They are made to pirate games and built on the backs of a zillion people that shared their into

thorny swift
#

But just something that stands out vs every other platform an emulator exists for

mental briar
#

It would be one thing to argue not open sourcing a calculator app. But this is a fucking emulator

gilded pagoda
thorny swift
mental briar
#

THAT IS SHIPPING ANY DAY NOW

#

FRAUD IS ILLEGAL IN SPAIN THEY HAVE TO SHIP ME THE CONSOLE - LEGALLY

dusk slate
thorny swift
#

Next knee based oopsie and they are gonna cut the damn thing out and install Terminator parts

ashen spoke
#

ehhh who cares, this core rocks and is getting better. all that matters

atomic fjord
#

Just played through AVP with the alien. Good stuff. I noticed saves don't work when I tried Wolfenstein 3D. I'm assuming the core just doesn't support them right now?

glad flame
#

Of course it rocks. It has Rayman! Everyone loves Rayman!

undone roost
#

It's better than the Lynx at least!

sterile moss
#

yeah saves arent written to SD yet

thorny swift
lunar latch
#

OK, "_faster2" just booted aliens 🙂

mental briar
mental briar
lunar latch
#

I agree, I have always wanted to try out Jaguar!!!!!

mental briar
#

It’s such a wonderfully bad system. It’s amazing to me that they charged money for some of these games.

Every system has shovelware, but the Jaguar went all out on that

dim sundial
mental briar
#

I don't think anyone would argue this time 😛

#

(I mean maybe - this is the internet)

dim sundial
#

the internet will argue anything to the death

mental briar
#

God bless us, everyone

thorny swift
#

🤣

ashen spoke
#

I don’t think this core is real, in the VGE videos you don’t see the mister running

#

and even then he could just be running a jaguar hidden behind the tv

#

Notice he never shows the core menu? Suspicious

mental briar
#

I'm telling you. Until I see Bacon standing next to a running mister, with the input clearly labeled, holding a newspaper with todays date on it, I won't believe him

#

I'll never trust Big MiSTer

dim sundial
dim sundial
gilded pagoda
thorny swift
thorny swift
mental briar
#

C H E M T R A I L S