Messages

[Buy/Sell/Trade / Re: Turbografx-16 & PC-Engine Reproduction Hucards Now for Sale!!!!]

...move forward with our next board design!

And we are on rev 3 of the board.

[PCE/TG-16|CD/SGX Discussion / Re: Fat HuCards]

<lol>
Retrocade was fat

[Localizations, Games, Apps, Docs / Re: ADPCM question....]

or call AD_STOP,  and check AD_STAT before you play the new sample.
(ie, if( AD_STAT() == 0 ) { play sample }


FWIW, AD_STAT() check one of the adpcm registers, and returns it in X, iirc.

[Localizations, Games, Apps, Docs / Re: The protocade...]

Does this still exist?  Link is down.

It's still up on the aetherbyte site. Just check and link worke fine for me.

[Localizations, Games, Apps, Docs / Re: Revival Chase - HuCard conversion?]

If you are looking to shrink things so you have some room, look at the size of your routines. You can often free up a few pages simply by moving short routines right after long ones. HuC doen't pack pages very full, so some code rearranging is probably in order.

If its really, really bad....Yeah compress the gfx. You can get nice results from compressing them

[Localizations, Games, Apps, Docs / Re: CD functions without the system card]

I'm not 100% positive (I could be wrong), but I Think there's already a block transfer instruction area at $26cc in the user area. It might be something HuC does, though. 
The other 'neat' option I saw was setting it up in an empty area in the card memory. The code tom posted has a tia (?) instruction that gets modifed in place, iirc

[Localizations, Games, Apps, Docs / Re: CD functions without the system card]

Thank you tom. And I don't see 128M per data track as a problem. Yet.

[Localizations, Games, Apps, Docs / Re: BRAM Library]

<edit>
256 K ROM
(16+15 = 31 * 8 = 256K)

[Localizations, Games, Apps, Docs / Re: BRAM Library]

I'm certain that the "additional" memory goes to $7F, to make memory contiguous.

Okay. Being wrong is part of learning.
I have a hard enough time remembering things, anyway. (At least since I turned XX)

So, to do this the card either has a 128K RAM + 64 K RAM + 64K ROM and a decoder sith some glue chips, or 3 * 64K RAM + 64K ROM + decoder....
Hmm. must have been a pain to get wired.

And the bios converts number-of-sectors to read to number-of-bytes to read, which is where the 64K limit comes in. Got it.
<Now, can it be fixed.....>

[Localizations, Games, Apps, Docs / Re: CD functions without the system card]

That I already have and use it from time to time, if you want it.

Yes, please.

Or make bi-compatible hucards. Function as normal hucards, or enhanced if used on a CD system

Or add extra levels on the cd...
(I'd love to see tuokos chuck no-rice game with loadable characters to use)

[Localizations, Games, Apps, Docs / Re: HuC questions.]

<edit>
Okay, you may be right.

I guess my disassembler has a problem, as it's thinking $2200 is the zp area.
that is,  I get lda    <cdTocBuf+1 .... but the opcode shows  a9 22......<sigh>
That's gonna set me back a bit....

And that timer value is  shown as inc  <$36.... with an data value of $e6.
Carry. on.

[Localizations, Games, Apps, Docs / Re: HuC questions.]

OK guys, you're scaring me here ... and I missing something crucial, or are we talking about different things? 

I don't think we're talking different things.....
The CD system BIOS uses the zp area, which is supposdly unused, to store parameters about the current CD. Like the TOC information. Current audio playing position. Etc.
It is interesting to note that $3a in the zp area is used in the standard timer irq routine, as an "I'm already handling this..." flag. (At least, thats what I think it is.)

The variables you are looking at in the zp are the ones common between the cd system and the stock routines for cards (I think) I believe a lot of the cd bios routines were also available as either source code, or a standard library for making cards.

Well, 8 levels deep with 4 ints per level is 64 bytes. Well within a 128 byte stack.

I guess I just don't get the point of using a zp stack area.
If it's going to be limited to 128 bytes, can't you do that on the system stack?
Why do it using semi-valuable zp space, which can be used for pointers, high-speed counters, general registers, etc?

If you're doing that in HuC, then you're generating some pretty slow and ugly code ... unless everything is already declared as a static.

Slow ugly code wasn't a problem while we were developing it, but yes, things got moved to static (ie ram) variables as part of the optimization process

I take it that you really mean "[temp],y" to access them. I guess that I'm missing something again. How is that an improvement over the current HuC "[stack],y"?

no, i really meant temp,x....but maybe I didn't exactly explain it clearly. The thought was to do it the same way most tia/tai/tii etc instructions are done; set up a small routine, with the address as a variable. Then you could call the routine to get the value. I realize its probably not faster, but it's doable. Hey, not all my ideas are -good- ones

Improving either HuC or CC65's actual internal optimization would be great, but is beyond my interest level.

No, not the internal optimization. A seperate optimizer program. That goes through the code (from either HuC or CC65 and rearranges/rewrites it in a more optimized form. Which you then assemble and/or link.
I still think it would be easier to do, and give you better optimized code.

[Localizations, Games, Apps, Docs / Re: HuC questions.]

Do you know why huc include a dummy .dw between each datas included ??

I'm not 100% sure whether I'm clear on what you're asking, but it could be to force 16-bit alignment on 16-bit word data.  At least, I seem to recall there was something like that.

Oddly enough, I think its actually the way Huc parses declarations and generates code.
With  a definition like " char x", it generates a 0 value.
Now change that to  "char x[10]", and it generates a 0 value. And then generates 10 more 0 values as space for the array.

Just for fun, look at the code you get for 'const char [10] = "abcdefghij"; '
IIRC, you get a 0 value, followed by 10 more 0 values, followed by the actual letters...
Though, I could be wrong. It's been a long time since I looked at that stuff.

[Localizations, Games, Apps, Docs / Re: HuC questions.]

Well, it's not as cramped as that, but the system card does allocate from the bottom up, and the top down.

Okay. I just checked and there's an area between  $90 and $DC that's not being used, afaik.
So yeah, maybe not too cramped for a stack area.

So, I would anticipate people passing 4 int variables in a function call.  I would anticipate 8-deep call levels.  And so I would anticipate corruption of variables due to exhausting all memory.  The target code would fail without warning (because who's going to put bounds checks in there ?), and the user would blame the compiler for his problems

+1. 8 deep level calls is not that unusual; 4 ints as parameters isn't either (consider Rovers 'example', where there are several variables, for setting up a sprite).

Not unless we're reading different manuals.

I'm not reading a manual. I'm looking at the system card code.
Granted, you probably could use most of the zero page for a stack...but you would lose access to the cd, since a lot of cd-related variables are stored from the bottom upwards (ie, $00+)
For example, you couldn't play a cd audio track, since the TOC information is loaded down there....

With a zero-page based stack you can take full advantage of the 65C02's instruction set and use "zp,x" (just look at the timings and the extra instructions).

or, given X is an offset, you could generate labels for the entire stack area, and access values as
'lda   <stk06'. No indirection needed. Right?
Yes, I know thats not  workable in reality.

What I pesonally think would be useful is to blend the current C stack and the ZP area stack.
The ZP stack could hold the address of a parameter block. Since the parameters would be consecutive, you could place the base address (stack,x) into a temp, then use [temp],x to access them. Not as fast, but not as limiting either.
(just an idea )


I still think a good advanced (ie, not peephole) optimization program could do wonders for even the lousy code HuC generates....

[Localizations, Games, Apps, Docs / Re: HuC questions.]

OK, next question ... what do people use zero-page for, and how full does it get?

Mostly, addresses for indirect access,  and high useage variables.
I think there are < 16 bytes free if you use the system CD stuff.

What do you think about putting C stack in zero-page (there are lots of advantages to the code)?

Why?

I think you are mis-understanding the zero-page. It's only 256 bytes.
Its the area of memory that can be reached with an address of $00xx  (well, $20xx on the pce)

[Localizations, Games, Apps, Docs / Re: BRAM Library]

Yeah, I set _DH to the MPR page and put the starting bank in _BL.

lda    #4    ; $8000 range / sta    _DH  /  lda  #80    /sta BL    kinda thing?

As I found out, there's a gap in page numbers...so it probably can only load 64K at a time.


[Syscard 3.0 banks are at $60-$6F, iirc. Then you jump to $80-$8F for 'stock' pages.
 I could be wrong though, with the ranges. I just remember they aren't consecutive.]

[Localizations, Games, Apps, Docs / Re: BRAM Library]

Ok. I tracked down the problem with BRAM code.

Good to hear. Now, when can we expect Dragon Warrior?

[Localizations, Games, Apps, Docs / Re: BRAM Library]

It's definitely an emulator thing with mednafen. I switched over to using the sys card bram routines instead,...

That sounds so damn familiar...I wish I could remember what we did to fix it...

First, check your mednafen.cfg file, and make sure its set up for bram saves; I vaguely recall if you don't specify a path for something, it won't actually save to a file.
Second, delete any old bram files you find. I do remember everytime I changed the cd image, mednafen created a new bram file (empty of course) with a different name. I believe the name was based on a hash of the code, and if things in the iso changed, you got a new save file.
Other than that ask the mednafen author what's going on / if he has any ideas. He's a pretty ok guy explaining why things do what they do. And if it's really an emulation problems, he does get it fixed.

Also, the CDREAD routine is annoying. I can only read in as many free banks as I have logical address range for (32k at a time)

The syscard 3.0 (?) CD_READ uses DH as a read type; the nice (or not) thing is you can specify an MPR bank to use for the read, and it is capable of filling consecutive banks for you.
And I -think- it may even load partial banks if the length isn't a multiple of 4 sectors.

Somewhere around there there used to be a HuCD7_final.pdf file that had the details on how the bios did things; not sure if it was 2.0 or 3.0, but the things it says do work on a 3.0 card.

That's how we figured out how to do MML

[Localizations, Games, Apps, Docs / Re: BRAM Library]

Ok, so I just tried it with bank $69 in mpr7 and bank $f7 in mpr4.

Okay. One more silly observation, then I'll leave it alone.
As I was tracing through the routines, I noticed that the bram re-lock routine turned the interrupts on.
So I went back and checked, and the bram unlock routine turns them off before going to low speed mode and unlocking bram.


[That's why one of the routines does some processing og the interrupts on it's own, I think. ]

[PCE/TG-16|CD/SGX Discussion / Re: Just... Bad, Turbo Ebay Auctions (Not Gouging)]

Remind me of this in 6 days. It's worth $10 just for the controller parts....

[Localizations, Games, Apps, Docs / Re: BRAM Library]

MPR2 is the $4000 cpu range, iirc.

My bad. I was just looking at something else, and noticed the syscard bram functions
save the entire memory layout. And then map actual BRAM data to MPR4 ($8000 range).

[Localizations, Games, Apps, Docs / Re: BRAM Library]

And in the CD project the bram code is in bank $69 and MPR 2. I'll MPR7 and see if that has any effect.

Hunh? MPR2 is the $4000 cpu range, iirc.  I'd have to trace through that stuff again, but I think thats actually where the BRAM 'appears' (I could be wrong, though)

Can you re-build the HuCard project as a cd, and see if it works? That will let you know if its a bank placement problem.

[Localizations, Games, Apps, Docs / Re: BRAM Library]

Seems I'm running into a problem using the same BRAM libs from a CD project.

It seems to me that if it works for a Hucard project, it should work for a CD project.
The only difference might be where the routines are located. I know the syscard version
is in the $00 bank, and mapped in at page 7 ($e000-$ffff). Possibly something is un-mapping your
routines / data. Or the emulator won't unlock BRAM from any other page.

[The system card routines use indirects to save to BRAM, since the data-to-save could be anywhere in the cpu address space. And the same for BRAM, iirc.]

[Localizations, Games, Apps, Docs / Re: BRAM Library]

Silly question: Did you format the BRAM? I vaguely remember having to do that to create the BRAM file for <Mednafen?> Look and see if theres a 2K file in with the emulator stuff.

Also, do you drop to low-speed mode?

[Localizations, Games, Apps, Docs / Re: HuC questions.]

IMHO, it's not worth my time and energy to mess with one of the compilers...

Just out of curiosity, have you thought about adding a seperate optimizer to the tool chain?
Something that could read the compiler output, and look for things to optimze, and then output a new version of the compilers output?

From what I'm seeing, all the math macros like compare, add, subtract, shift, multiply, etc are all hard-coded for 16-bit values in X:A.

Probably.  I think it would be hard enough to get right in a limited case, much less write a macro that handles all the possibilities. (But then, I'm not that good at asm. I have enough trouble with compares when I know the sizes <lol>)

That is what the last patch I made to HuC does, since I was working on the 240p test suite version for system card 1.0.

Someone should really gather all the patches together, and release an updated HuC.

[Localizations, Games, Apps, Docs / Re: HuC questions.]

Should I be looking in the code-generator itself?

Its not how HuC generates the code; it basically generates macro calls to do things, iirc.
It's in the macros themselves.

For example: if  HuC generates a __phw call, it eventually resolves to something that checks the size
of the operand to generate different versions of the function. See huc_opt.inc for that macro, and others that do a similar thing.

I found that example in a .lst file. The macros seem to be used to get pceas to generate the right code. I don't know how to explain it, but it works.

[Localizations, Games, Apps, Docs / Re: HuC questions.]

it looks like everything is done as 16-bit values.

Not quite. Some (most?) of the macros check the size of the given value, and omit the high byte code if a char gets passed.
In general, though, HuC only deals with ints. And it won't cast a char to an int, either

[Localizations, Games, Apps, Docs / Re: HuC questions.]

If you do some work with HuC, adding these feature would really help it out IMO.

I'd settle for it remembering how much space is empty in each bank, and trying to fit functions in where
there is empty space.

[Localizations, Games, Apps, Docs / Re: HuC questions.]

It looks like there's a bank for constants ... not sure why. What else? Where do they go?

There's a bank for constants; I assume its because they can be mapped in and out when needed. I believe thats bank 3, but i could be wrong.
There are 2 banks for the 'stock' libraries; banks 1 and 2, iirc.
Then there is a bank for the startup code. Bank 0, which gets mapped to $e000-ffff.
...
If I remember correctly, the startup code contains some of the library functions, while another bank
contains the rest. The 'secondary' library functions get mapped in/out via stub calls in the first library.

What I am fairly sure of is that HuC will leave a window of 3 banks for mapping code in and out for CDs. If you're building a HuCard image, I -think- the page at $c000-$dfff  is available, also. Somewhere in the HuC docs there is a file explaining how things are set up.

Other than that, HuC generates code into the next available bank, as needed. Beware of this though - if a function won't fit into the available bank, it gets put in the next one. The unassigned space is not recovered.
And, if you define a user bank (ie, for assembler routines), it becomes the next available bank, and any unfilled banks before it are ignored. That is why re-arranging functions can sometimes lead to a huge reduction in memory useage.

[Localizations, Games, Apps, Docs / Re: Dragon Warrior for PCE]

I could never understand why Tandy released the CoCo3 ... but then I wasn't in America at the time.

I think a lot of that was trying to give the diehards what they wanted.
The original coco 1/2 was limited in memory (128K, max, iirc), and when OS-9 got released, a lot of people wanted/needed more RAM. So the 3 upped the ante to 512K, with a new OS to use it.
It was a really sweet machine to me, coming from using Vax's at work....

Naturally, CoCo3 users found out about this CPU's secret and put them into their Cocos.

Yeah. The 6309 mod is probably the only one I was afraid of trying <sigh>. At that age (20's), removing a CPU was frightening. Though I might have tried it if someone had made a dual CPU switchable board...

[Localizations, Games, Apps, Docs / Re: Dragon Warrior for PCE]

It was the computer I had when I was a kid (CoCo 2 and CoCo 3). Though I couldn't afford OS-9.

Still got it?
I still have mine... a Coco 1 w/replacement keyboard.

[PC-FX Discussion / Re: PC Engine II - GamePro Rumors Column]

I think that you may be thinking of a few years later,

Ok, my bad. Just asked the nephew to verify, and he says he was in middle school (7-9 grade). Sine he was born in 81, that would make it 93-94.
Do remember it was a first home model burner. I got it to make mix cd's for an ex. The XMas before, I got her a cd player, but she had nothing to listen to (except the beatles white album and pink floyd dark side)

[PC-FX Discussion / Re: PC Engine II - GamePro Rumors Column]

This was written in 1991. CD-R technology was very new, and burners cost approx $30,000.

Uh, no. My first burner (a 1x ricoh) was about $500. Throw in the scsi card needed to run it at another $200. Heck, Throw in the pc, too, at $2500.

Still less than $10,00. MAYBE total, $5000-6000.
If you already had the pc, less than $1000 more.

[Localizations, Games, Apps, Docs / Re: Dragon Warrior for PCE]

Hmm. Maybe I could even go a step further with __GetBRAMByte, and have the return jump be from a table. And the index (into the jump table) would be the register in which the function that called it, would set the return address.

I did something sort of like that once; fix stack pointer, then get the return address from a table and push it. Then when the function returned, it went back to the chosen function.
Was neat to try, just to see if it would work.

[Buy/Sell/Trade / Re: Turbografx-16 & PC-Engine Reproduction Hucards Now for Sale!!!!]

as far as trace routing, that was mostly done by hand

You have more patience than I do.
I just turned the chip.

[Buy/Sell/Trade / Re: Turbografx-16 & PC-Engine Reproduction Hucards Now for Sale!!!!]

So you're saying that they stole the internal pcb design?

You do know that circuit design software will lay out the traces for you, don't you?
All you have to do is match the names.

(Btw: I believe its done via a layout program because of the way the traces look in the pictures. Human layout would have realized really quickly that there's a much more straightforward way to do it.)

[Off-Topic / Re: What do you drive…]

.... would smell worse than bigfoots dick.

How would you know that?

(yes, I understand it's hyperbole - an exaggeration.)

[Localizations, Games, Apps, Docs / Re: BRAM support]

On that note: does the system card take care of defragmenting the entries?

I take my comment back. I just checked, and it looks like it shifts the directory/data blocks backwards, over writing the old data, and adjusts the available pointer.

Must have been thinking of the HuC version....

[Localizations, Games, Apps, Docs / Re: BRAM support]

So what about the linked list system? Is there a WORD pointer at the end of an entry?

Don't believe so. It adds up the entry sizes. Recognizes list end by comparing to next available byte.

On that note: does the system card take care of defragmenting the entries?

<lol>. No, I don't think it does.

[Buy/Sell/Trade / Re: Turbografx-16 & PC-Engine Reproduction Hucards Now for Sale!!!!]

Okay, problem not solved.

I doubt there would be enough room for the diodes/resistors needed.
You -might- be able to squeeze a level-shifter on there, if it's small. Would we need 2? (input+output?)
Any idea of what kind of delay would that cause...?

Assuming we can't find a stash of big enough 5V CPLD/PGA's somewhere...

[Localizations, Games, Apps, Docs / Re: Remind me how to use my "Low-Cost Flash HuCard"]

Mine sometimes has an issue erasing the rom

If thats about the gameofyou cheap flash card.... try lightly resting a finger on the left chip, and see if that helps.

[Buy/Sell/Trade / Re: Turbografx-16 & PC-Engine Reproduction Hucards Now for Sale!!!!]

as far as 5V it wouldnt be required on the cpld as the RAM can be 5V and drive the outputs
a 3.3v chip can address a 5V chip fine

+1 problem solved.

[Buy/Sell/Trade / Re: Turbografx-16 & PC-Engine Reproduction Hucards Now for Sale!!!!]

IMHO, you should only need a fairly simple FPGA/CPLD to do the Arcade Card ... your problem is more going to be in the number of I/O pins that you need, and the total number of individual IC chips ... trying to fit a CPLD, ROM, and 2 RAM chips into the space that you've got is going to be ... interesting.

I agreee. But there's room for 2 memory chips (Ram or Rom) underneath the board; then you have the
whole top area for the FPGA/CPLD and a memory chip. Which actually might be doable. (Though I think you would need a multi-layer board to do it.)

Ss far as CPLD/FPGA/RAM choices, well you don't have that many anymore if you're talking about using 5V parts...

Always a problem with older systems, unfortunately.

Is the Arcade Card Pro really that rare that it's worth going to all that trouble?

Probably not. It's a Nice design problem, though.

Errr ... don't we already have that "super" Arcade Card with the Turbo Everdrive 2?

Not that I am aware of. Doesn't the arcade card have extra registers? (I'm pretty sure there is at least a shift register available.) Are those emulated on the TED 2?
Extra memory is nice, even if it's single-byte access via a register. Shift register would be nicer, making multiplies and  a few other calculations easier/faster.

[Localizations, Games, Apps, Docs / Re: Look Up Tables in HuC?]

It was actually all pretty funny. He did Insanity for the spring semester, and mentioned that it would be neat if he could put it on CD and sell it.
He was really surprised when I pulled out some old bootlegs I made: Space Invaders, one of the Macross games, and Dracula X. Then we spent the entire summer learning the CD-system, adding music (and voices) and of course figuring out how to make a CD.
I never expected he would actually get it made and sell it.

BTW, Arkhan wasn't the first guy who asked me for help writing a game. He was just the only one who was willing to do the actual work (rather than say "It needs to do this" and expecting me to make it happen).

[Buy/Sell/Trade / Re: Turbografx-16 & PC-Engine Reproduction Hucards Now for Sale!!!!]

...as far as space we have about 0.040 chip height to play with and are using TSOP now

Height isn't the problem; we know theres enough room underneath for Flash / Ram chips. (Rams are same height at Flash; Flash chip fit underneath, so there's no problem).
The problem is surface area; only about 1/2 of the top area is available for mounting chips. A large programmable chip might use all/most of that. You would have to find one with enough gates to duplicate the arcade card registers, and a small enough area to fit on the board.

I know only that programmable chips exist, and come in different gate counts. IIRC (and I may not), number of gates is proportional to surface area, so more gates == bigger area.

If you are serious, or just want to learn more about the chips, maybe you could contact Kevtris on the atari age forums; he's been doing cpu emulation via fpga's. Maybe he can help recommend one to use.

And somewhere around here (and in HuC files) is a description of the arcade card registers. Looking at that might give you an idea of what you would need, in terms of gates, etc.

I still think it's doable; I just don't have the in-depth knowledge it would take.

[Buy/Sell/Trade / Re: Turbografx-16 & PC-Engine Reproduction Hucards Now for Sale!!!!]

... new, cheap, repro Arcade card

Yes it can probably be done. Would need a programmable chip (PGA/CPLD) to do the registers, and
extra RAM chips. The real question is if there is enough space on the board for everything...But you would have both sides to work on, so probably.

[Buy/Sell/Trade / Re: PCFX arcade pad?]

..4bits=nibble

Actually, half a byte is a nibble

It's just most bytes are 8 bits now.

[Localizations, Games, Apps, Docs / Re: Look Up Tables in HuC?]

I wonder if I could get credit for "independent study" course if I worked on HuC. Heh.

Probably. That's how Insanity started....

[Console Repair/Mod Center / Re: PC Engine PI-TG001 issues]

pins4 and 30-32 concern me

That's A16, A13, A14, and A17, right? During boot up it reads page 0, so I could see those being 0V.
Not sure why A15 (pin 5) would be fluctuating though, so it could be an address line problem.

i thought that was without card

Wouldn't you see 0's without the card?
Either way, they should be fluctuating as the cpu acceses the card, if the addresses are changing. (As they appear to be).

My next step would be to check for a shorts between the pins, both with and without a card inserted (but with the machine off).  I know the card slot can get worn, and the connector fingers either don't make contact, or short 2 connections together. After 20+ years, it can get touchy about how the card sits.
Might be as simple as inserting the card to one side or the other of the connector.

If all seems good, its time to get a logic probe, I think.

..................................................................................................
Just to satisfy my curiosity, (and the original reason I replied at all), did your friend really
tell you to 'put a 1' on pin 1? You can tap 5V from the 7805 for that...but I don't recommend it.
Pin 1 (/CD) connects to ground inside the card; without a current-limiting resistor you'll probably blow either the 7805 or something in the card.

I'm not an expert but even I know you don't short power directly to a ground without -bad things- happening..

[Buy/Sell/Trade / Re: On sale for a stupid price]

Easily explained. He had hundreds of copies he couldn't get rid of, but 50 that he could get rid of. Those are the ones that were sold; he still has the hundreds that he cannot get rid if.

Sorry, I read that differently. I read "He has (had) hundreds of copies; the 50 he had listed sold out in 24 hrs.". Possibly he still has another 50 or so to go

Maybe Arkhan should be pimping Insanity and Pyramid Plunder here. Last I knew he had quite a few of each leftover...
<Alas, no Atlanteans until the printer gets fixed...again.>