Jump to content
IGNORED

Lynx Multi Cart


SainT

Recommended Posts

 

Ok, got some code running on the Lynx to test the CE1 strobe output to the cartridge. I have an interrupt setup on the PIC to trigger on the falling edge of CE1 which seems to be working fine, but I just need to know how to set the AUDIN pin high as I'm using this to determine the data transfer direction on CE1 (0=read, 1=write). Lynx coders help please. :)

 

Something like --

 

lda #16
sta $FD8B
But is $FD8A setup correctly for output on AUDIN at boot? If not what value should I use here? And what should the other bits be set to in $FD8B normally?
I would test this but I need some sleep. Any help appreciated. :)

 

 

Like Karri said, the setting of $FD8A is different for L1 and L2. But you can set it to whatever you want, as long as you do not rely on a specific setting of the AUDIN bit before you are able to change/set it.

In short, I believe it doesn't matter what the initial value is. The games Karri mentioned use the AUDIN line as an additional address line. That implies that it can go to bank1 or 2 depending on the hardware. Does this apply to your situation as well?

Anyway, the boot ROM will set the following:

ff89 a0 02 LDY #$02
ff8b 8c 8b fd STY $fd8b Cart power off
ff8e c8 INY
ff8f 8c 8a fd STY $fd8a External power and cart address to 

This is the relevant part of the Epyx documentation:

FD8A = IODIR.Mikey Parallel I/O Data Direction (W)reset = 
0,0.0.0,0,0,0,0
8 bits I/O direction corresponding to the 8 bits 
at FD8B0=input, 1= output,
FD8B = lODAT.Mikey Parallel Data(sort of a R/W)8 
bits of general purpose I/O data
B7 = NCB6 = NCB5 = NCB4 = audin 
inputB3 = rest outputB2 = noexp inputB1 = Cart Address Data output 
(0 turns cart power on)B0 = External Power input(note, R0M sets it to 
output, you must set it to input)
Note that some lines are used for several functions, please read the 
spec.Also note that only the lines that are set to input are actually valid 
for reading.--READ THE SPEC----

and some more here: http://www.monlynx.de/lynx/lynx9.html#_07

 

Hope this helps. I was away for business and slow to response. I hope to be able to reply faster next time.

  • Like 1
Link to comment
Share on other sites

I happen to think that because of Lynxmans flash cart you have multiple games on the way from LX.NET, at least 3 more from me. So no, it's not bullshit.

 

EDIT: It's also not just about flash carts and SD carts here, it's the fact that LX.NET produced an awesome tutorial which people are still discovering. I really believe that the home brew scene can only grow from here and those great tutorials combined with flash carts and SD carts is a good thing. Sure the elite will always say they don't need flash carts and SD carts but its about appealing to a wider audience - the more people that become interested enough to purchase a Lynx and SD cart means there's more chance of attracting other developers.

Edited by GadgetUK
  • Like 3
Link to comment
Share on other sites

I agree with Gadget, Guitari and Omnibot. Lynxman's flashcard has done good for the Lynx community. It has made development easier, and given fans a way to actually enjoy homebrews. There are several really big projects in the works, some stuff released already, and the flashcard is a reason for that. It is a nice, productive scene now, albeit small.

 

The new flashcard with SD card support will further simplify the handling of a flashcard; in turn making it more attractive, just as having lots of games on it at the same time. For the developers this will be less of an important thing, although I think they will also like to drag and drop stuff on the SD card simply. But the consumer, for him not having to deal with a terminal program flashing every single game will make a huge difference.

 

The flashcards, a potential new LCD, and the productiveness of homebrewers are key to attracting people. I wouldn't be here myself had it not been for the homebrew scene.

Link to comment
Share on other sites

Yeah, we have the discussion every few years, but my attitude has not changed. My arguments are still the same.

Person A: "Cool, maybe this flash cart will spark interest in homebrew development."

 

Person B: "BULLSHIT! IT WILL NOT! RARHR!!!"

 

Great argument.

  • Like 2
Link to comment
Share on other sites

Slight update, has been a little while. :)

 

I have the Lynx talking to the cart now (I have received a byte!) so tonight I've been setting up the command processing structure on the PIC micro to handle opening directories, reading them, opening files, etc...

 

Mostly in place now for doing a directory read, so hopefully will get some time tomorrow evening to write some code on the Lynx and test.

 

And for those who are interested, I've changed my plan slightly. I'm now using the AUX pin as a handshake to tell the Lynx if there is data ready to be read or if the write FIFO is full, so there's no chance of losing any data. I'm not sure how quick it's going to be given the speed of PIC C, so this mechanism looks like it's going to be essential to make sure data isn't lost.

  • Like 5
Link to comment
Share on other sites

  • 2 weeks later...

Wow...I started from page 1 and read this whole thread! It's be so fun seeing progress being made, etc....I'm excited for this! I'm still new to Lynx (well, i got one when they were new, only to have it stolen two years later but just got back into it). I've got a Lynx I and Lynx II and 9 cartridges with 4 more on the way, so I'm building up my library. I am anxious to see how these will look finalized with menu, etc....keep up the good work! :)

  • Like 1
Link to comment
Share on other sites

Meh, is it just me or is cc65 so buggy its unusable?

 

For example...

strcpy(gsDirEntry[0].szFilename, "Arrr");

works. However...

strcpy(gsDirEntry[nEntry].szFilename, "Arrr");
strcpy(gsDirEntry[0].szFilename, pIn);

(where nEntry = 0) do not.

I dont know if I can be doing anything wrong, but really basic C code is failing to produce the results I expect. Really doesn't fill me with confidence... :(
Edit: I've tried all the different optimisation / local register setting I can find and it still generates bad code. gsDirEntry above is just a global directory entry array. If anyone knows of any workarounds to get cc65 actually working I'd appreciate it, as I'm a bit stuck without a C compiler that works... :(
Edit2: I've just double checked the code behaves the same on the Lynx as it does in Handy. And it does... so it's not the emulator at fault. :(
Edited by SainT
Link to comment
Share on other sites

What kind of error are you getting?

 

The memory pointed to by szFilename in the above code is not touched at all.... it's like the pointer passing or address generation for the pointers is buggered.

 

Another example...

gsDirEntry[0].szFilename[0] = 'a';
gsDirEntry[0].szFilename[1] = 0;
strcpy(gsDirEntry[0].szFilename, pIn);

Where pIn = "Hello!", I get "a" printed out on screen, so any copying in strcpy just fails (most likely ending up at the wrong address).

 

Or another one, if you change 'a' for *pIn, you get "H" on screen. So its the call to strycpy which just doesn't work. However in the example above using a string literal, the call to strcpy does work. Something is very wrong somewhere...

 

Really frustrating as this is very nearly working now.

Edited by SainT
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...