Frustrated

[Malban]

Hi,
I must confess at the moment I am extremely frustrated.
IMHO the smart card behaves a little erratic. The attached BASIC file is supposed to play YM-Data. The code is most probably correct. My smartcard quits loading with "out of memory" (I especially used a small YM file).

If you delete some of the data statements (so that the file is about 100 lines shorter) the music plays alright.
There is NO definite point where the memory error disapears! Sometimes at 150 lines, sometimes at 170... etc.
(In the manual it says Strings can be up to 4GB - is there a limit on line lengths? I am pretty sure 150 lines of data does not come near 4 GB - but I have not found a limit on line length, or how else to enter large quantity of data)

Once an out of memory error occurs, the smartcard does not react in any way any more - only switching vectrex off/on helps - which I did the last hour about 50 times - I will stop that now! My poor vectrex.

Since for the last couple of years I have been programming other languages than BASIC - while editing programs there are bound to be mistakes, some wrong thinking - some plain syntax errors.

However the error descriptions the BASIC provides are most of the time (or at least with the errors I make - very often) not helpfull.
Little example of a small stupid mistake:
instead of writing:

Code Select Expand

function initYMData()
return  { _  MUCH DATA_
}
endfunction

I accidently wrote:

Code Select Expand

function initYMData()
return = { _  MUCH DATA_
}
endfunction

The program does not LOAD anymore, the loading quits with the message:
"Invalid expression"

I had a couple of other (once you found them stupid) errors/error messages. However I have not kept a log and the errors are now gone ofter enough trial and error.

Forgive me - but for now I will rest doing BASIC stuff.

Malban

[Vectrex32]

Hi Malban,

I'm sorry for the problems you're having.

First, the issue with the huge array initializer is that the statement (i.e. from "data = { _" all the way to the last end brace) is 19K. I did not anticipate a statement being this big. The code tokenizes the entire statement before compiling it, and I should see if I can re-architect that to tokenize on-the-fly.

I tried breaking up the huge initializer into multiple statements by initializing smaller arrays and appending them together (using AppendArray). That allowed the program to load. When I ran it, it started building the big array but crashed when it tried to allocate a 24K block of memory. I suspect memory fragmentation but I need to look into it more.

That "Invalid expression" error should have given you a line number. Other error messages print out line and column numbers. I have found this bug and it will be fixed in the next firmware release.

I should handle memory errors more gracefully and/or add a reset button to the SmartCart.

Again, I'm sorry for the bugs and the frustration. I'll work on fixing the former and hope time will heal the latter.

- Bob

[Malban]

No worries :-) - I have many other things todo :-).
I know that one can not test all facets of a new product prior to launching.

Thats what error reporting an forums are about...

Regards
Malban

[Vectrex32]

Hi Malban,

Here's an update: I have fixed the memory problems. However, I'm having a problem with the firmware upgrade mechanism, so I need to work that out before I release the fixes.

Sit tight.

- Bob

[Pix]

I'm having a similar out of memory problem. Not sure if it's the same cause or not as I'm not trying to create any especially large arrays.

In brief, I'm attempting to port over an old Apple II game called Akalabeth (a very early first person dungeon crawler). I've been adding a load of functions to draw the 10 monsters in the game each of which has an array storing the data to draw the lines. Everything ran fine until I got on to #9 and 10 but it now just throws out of memory errors when trying to load the basic unless I delete the contents of some of those functions. None of the arrays are especially large so I wouldn't expect to be having any problems. The code is attached - is this the same bug?

Cheers,
Rich

[Vectrex32]

Hi Pix. I'm sorry for the problem. I am able to reproduce it with your program on version 1.00 but the problem no longer occurs on the latest version of my code. So I believe I have fixed it.

I'm putting the final touches on the next version. In addition to bug fixes, it's going to support 3D graphics! But here's the bad news: my mechanism for upgrading the firmware is buggy in version 1.00 and I can not find a workaround. So when the new code is ready, I'm going to have to do a recall to upgrade the Vectrex32s that have already been sold. This is my fault and I will refund everyone's shipping costs.

When I'm ready to release the new code, I'll be announcing it in the Vectrex32 forums, the VFU facebook page, and on vectorgaming.proboards.com. I hope to do this in the next couple of weeks.

- Bob

[Pix]

That's mostly good news at least. I'm loving the prospect of 3D support on a Vectrex. I'll hold off on playing around with this any more for now at any rate.

Can I ask that when you send the cartridge back again you don't put down the actual value on the customs declaration. I've already had to pay out $60 in customs fees and really don't want to have to do the same a second time. I'll mark it with a low value myself when sending it back.

Cheers,
Rich

[Vectrex32]

Hi Pix,

Given that you've already paid customs and you're returning the item for repair, I don't think either of us are required to pay customs. If you take the package to the post office, tell them that you paid customs when it was imported and you're returning it. They might even have a checkbox on the form for this. Then when I send it back to you, I'll mark it "return of personal property" or whatever my post office recommends.

- Bob

[Vectrex32]

The bug fixes and new features are available. Please see http://forums.vectrex32.com/index.php/topic,28.0.html

[Pix]

I've checked the terms and I apparently have to be able to provide a copy of the guarantee/warranty agreement to my shipping provider when it's returned. If you can put some documentation to that effect in the parcel, it may help if it comes to that. I would have to pay customs on any repair costs or on the price of the item in full if it was replaced rather than repaired so it needs to be clear that it was repaired under warranty for free.

I'll get it back in the post to you tomorrow.

Cheers,
Rich

[Vectrex32]

Thanks for letting me know. I'll include a Warranty Repair - No Charge invoice in the packages I send to my non-US customers.

- Bob

[Pix]

The fixed cartridge has arrived back safe and sound with no charges to pay. 

I've been playing around with it again this evening and added in the rest of the graphics for this Apple II game I'm trying to port over. The memory issues have definitely improved but I'm running into out of memory errors again now despite the code only being about 20k.

I've attached the code in it's current state. With the extra testing subroutine in there eating up a bit more space, it gives an out of memory error immediately on running. Without that, it will start but crash when drawing one of the more complex monsters. Any ideas what is going wrong?

[Vectrex32]

I am able to reproduce the problem. I'm looking into it.

- Bob

[Vectrex32]

Hi Pic,

I've fixed the problem and released a firmware upgrade, version 1.13. I'm now able to load and run your program, even with that large, memory consuming test function you added. You can download the firmware from http://vectrex32.com/version-1-13-upgrade/ and follow the instructions to install it.

Keep in mind that Vectrex32 compiles your BASIC program into an intermediate form that consumes a lot more memory than the BASIC code itself does. Still, I was able to find several opportunities for reducing memory usage.

I'm a little puzzled by the way you make Lines sprites. You create arrays with "M" and "D" values, then copy them into new arrays, replacing the strings with MoveTo and DrawTo. MoveTo and DrawTo are just built-in constants that are the integers 0 and 1; they consume a lot less memory than the strings "M" and "D". Creating new arrays and copying the values over also uses memory, time, and complicates your code. Why not just define the original arrays with MoveTo and DrawTo?

My only guess is that you were trying to reduce the amount of typing. But if this is the case, you could create global variables M = MoveTo and D = DrawTo, and use those when creating the arrays.

BTW, when I ran your game, it looked very intriguing. I'm looking forward to seeing the finished product.

I hope this helps.

- Bob

[Pix]

Thanks very much. I'll give that a go later this weekend.

The line drawing function was an attempt to reduce the size of the code itself when I was struggling to get it to load on version 1.0.  It did appear to help at the time but I'll get it changed as you suggest. I had the notion of adding the point drawing to the arrays at some point that a few of the monsters use for eyes.

I wouldn't necessarily look forward to the finished version of this game too much. In truth, the original that I'm porting from wasn't all that much fun in the first place. It just seemed like a good choice at the time since Akalabeth used near enough nothing but line graphics and was written entirely in basic.  I figured a quick port would be an easy way to learn my way around programming on the Vectrex32. All the graphics are in there now anyway, I just have to build the actual game part.